Mistakes made because of the differences between various Unix/Linux flavors

News Enterprise Unix System Administration Recommended Links Simple Unix Backup Tools Unix rm command Unix mv command
Absence of backup Rush/absence of testing Creative uses of rm Abuse of privileges LVM and disk related mishaps Working on the wrong computer
Safe-rm Typical Errors In Using Find Tips Unix History Humor Etc

Introduction

In most case differences between flavors of Unix are just annoying but in some case then can became source of serious errors

Differences between flavors of Linux such as Red Hat and Suse can also also lead to unintended consequences. And some of them are really devious because the working assumption for syadmin is those two flavours of Linux are "almost identical".  For example, if  in one of those flavours a particular daemon  is started via RC scripts and in other via xinetd. Often people even do not understand that different methods are deployed and start manually daemon which should be started via   xinetd.

Also RHEL and SUSE has different security mechanisms in place. The SUSE administrative tools seem to be  superior to RedHat (WebYast,  Yast2), while authoyast is vastly inferiors to kickstart (and was way too buggy until SLES 12, when Yast was rewritten in Ruby).

But real fun starts when scripts designed and tested on one flavor of Linux or Unix are moved to the other. Here even innocent differences in location of files such as /var/log/messages on Suse and Red Hat  vs /var/adm/messages on Solaris can led to interesting side effects.  Another good example is that on HP-UX df command prodiuces completly different output then on all other flavors of Unix.  You need to use bdf to get similar output.

Default locations of many classic Unix utilities differ and if script uses absolute path some commands might never be executed. Just because it works one flavor of *nix does not mean that it will work for another. That also means that you should never ever assume that some prepackaged script that you downloaded does anything right. Running such script without testing can be quite suicidal as they do not always check if particular cd operation is successful.

Sometimes scalability cause serious problem. It's one thing to run a particular script on the server with 10 users and the other with 10000 users:

...Management told us to email a security notice to every user on the our system (at that time, around 3000 users). A certain novice administrator on our system wanted to do it, so I instructed them to extract a list of users from /etc/passwd, write a simple shell loop to do the job, and throw it in the background.

Here's what they wrote (bourne shell)...

for USER in `cat user.list`;
   do mail $USER <message.text &
done

Have you ever seen a load average of over 300 ???

Subtle differences between bash and ksh

Note: You might be better off forgetting all this silly noise about compatibility and using bash. Bash is now standard de-facto and is available of almost all enterprise flavors of Unix and commercial Linuxes.

It is still not available on HP-UX 11 by default, but you can install it from a depo. Anyway even they provide bash with binaries available for all HP-UX versions.  It is actually much easier to install bash on all systems that struggle with shell compatibility questions.  Solaris, AIX and linuxes have bash installed out of the box and now bash in the natural least common denominator of shells.  Moreover bash 3.xx is pretty close to ksh93 and if you tested you scripts with it, in most cases the script should work OK.  That main difference is treatment of the last stage of pipeline, but now there is bash option via which you "enforce" ksh behaviour (which is actually the only rational behaviour ;-).

Originally sh was Born shell that has a separate implementation. Those days sh is often implemented as a special compilation of existing ksh version (or bash) and in most cases it does not make sense to use Born shell. You will be better off using bash

The second problem in writing portable script is that there are also many subtle differences in utilities provided and their location for various flavors of Unix. There are several ways to deal with this problem. One is to provide symbolic link to "most reasonable location", the second is to provide wrappers and the third that probably the most popular is to encode path and the name of the utility in shell variables.

Both the Bourne shell, and the Korn shell, can use the semicolon and the carriage return interchangeably in their syntax of the if, for, and while built-in commands.  When using the brackets ([ ]) within if commands, you must separate both inside ends of the brackets from the inside characters with a space.

Shell Script Porting Guidelines

Here is a semi-useless table from the FAQ that compares shells.  It is old and from purely academic point of view is incomplete as it does not include ksh93 which is in many respect the pinnacle of traditional Unix shells. But again you need to forget about academic discussion here: it is simpler to switch to bash then struggle with all this stupid complexity. Bash is not perfect but it works well enough to suit your needs. Sometime the best way to conquer obstacle is to go around it :-)

                                    sh   csh  ksh  bash tcsh zsh  rc   es
Job control                          N    Y    Y    Y    Y    Y    N    N
Aliases                              N    Y    Y    Y    Y    Y    N    N
Shell functions                      Y(1) N    Y    Y    N    Y    Y    Y
"Sensible" Input/Output redirection  Y    N    Y    Y    N    Y    Y    Y
Directory stack                      N    Y    Y    Y    Y    Y    F    F
Command history                      N    Y    Y    Y    Y    Y    L    L
Command line editing                 N    N    Y    Y    Y    Y    L    L
Vi Command line editing              N    N    Y    Y    Y(3) Y    L    L
Emacs Command line editing           N    N    Y    Y    Y    Y    L    L
Rebindable Command line editing      N    N    N    Y    Y    Y    L    L
User name look up                    N    Y    Y    Y    Y    Y    L    L
Login/Logout watching                N    N    N    N    Y    Y    F    F
Filename completion                  N    Y(1) Y    Y    Y    Y    L    L
Username completion                  N    Y(2) Y    Y    Y    Y    L    L
Hostname completion                  N    Y(2) Y    Y    Y    Y    L    L
History completion                   N    N    N    Y    Y    Y    L    L
Fully programmable Completion        N    N    N    N    Y    Y    N    N
Mh Mailbox completion                N    N    N    N(4) N(6) N(6) N    N
Co Processes                         N    N    Y    N    N    Y    N    N
Builtin artithmetic evaluation       N    Y    Y    Y    Y    Y    N    N
Can follow symbolic links invisibly  N    N    Y    Y    Y    Y    N    N
Periodic command execution           N    N    N    N    Y    Y    N    N
Custom Prompt (easily)               N    N    Y    Y    Y    Y    Y    Y
Sun Keyboard Hack                    N    N    N    N    N    Y    N    N
Spelling Correction                  N    N    N    N    Y    Y    N    N
Process Substitution                 N    N    N    Y(2) N    Y    Y    Y
Underlying Syntax                    sh   csh  sh   sh   csh  sh   rc   rc
Freely Available                     N    N    N(5) Y    Y    Y    Y    Y
Checks Mailbox                       N    Y    Y    Y    Y    Y    F    F
Tty Sanity Checking                  N    N    N    N    Y    Y    N    N
Can cope with large argument lists   Y    N    Y    Y    Y    Y    Y    Y
Has non-interactive startup file     N    Y    Y(7) Y(7) Y    Y    N    N
Has non-login startup file           N    Y    Y(7) Y    Y    Y    N    N
Can avoid user startup files         N    Y    N    Y    N    Y    Y    Y
Can specify startup file             N    N    Y    Y    N    N    N    N
Low level command redefinition       N    N    N    N    N    N    N    Y
Has anonymous functions              N    N    N    N    N    N    Y    Y
List Variables                       N    Y    Y    N    Y    Y    Y    Y
Full signal trap handling            Y    N    Y    Y    N    Y    Y    Y
File no clobber ability              N    Y    Y    Y    Y    Y    N    F
Local variables                      N    N    Y    Y    N    Y    Y    Y
Lexically scoped variables           N    N    N    N    N    N    N    Y
Exceptions                           N    N    N    N    N    N    N    Y

Key to the table above.

   Y      Feature can be done using this shell.
          
   N      Feature is not present in the shell.
          
   F      Feature can only be done by using the shells function
          mechanism.
          
   L      The readline library must be linked into the shell to enable
          this Feature.


NEWS CONTENTS

Old News ;-)

Comparison of SLES (SUSE) and RHEL (Red Hat) on IBM System p

18 November 2008 | ibm.com/developerworks

... ... ...

What you won't find with RHEL is an integrated GUI-like YaST2, from which you can launch any command that your heart desires. With Red Hat, you have GUIs, but you need to remember the names of the commands that launch them; there is not one command from which it all flows as there is with SLES. To add logical volumes, you'll use the system-config-lvm command. The first thing you'll need to do prior to setting up our volume group is initialize your unpartitioned space (see Figure 8), which, here, is 20 GB: # system-config-lvm.

[Mar 23, 2006] Microsoft today published an IDC report which looked at issues related to Unix migration

Hat tip to Solaris Migration resources in the SPARC Product Directory

IDC interviewed 400 Unix/RISC customers about their attitudes to migration. The average interview time was 30 minutes. It makes very interesting reading. The report says Sun is the main target for migration and the clock is ticking. Here are some extracts...

"Sun Solaris continues to be the most popular Unix variant for Unix servers running Web infrastructure. While this is not surprising given the dot-com success that Sun enjoyed in the late 1990s and into 2000, it does continue to represent a challenge for Sun because these workloads have been frequent targets for migration over the past five years."

"IDC believes that the server life-cycle issues are driving much of this change, because the systems in the Unix installed base have aged in recent years, and this is compounded by the fact that many dot-com era installations with Web enablement of business workloads, are coming of age and will require replacement. In addition, many Unix/RISC servers were deployed in preparation for Y2K and many of these systems are now nearing the end of their useful life cycle." ...read the article (pdf), ...IDC profile, Solaris Migration Resources

Recommended Links

ORACLE-BASE - UNIX Commands for DBAs

AIX to Solaris

AIX to Solaris Operating System Migration Solutions

Linux to Solaris

Linux Migration Guide - OpenSolaris

Migrating from Linux to Solaris or OpenSolaris - Solaris Developer ...

Solaris to Linux

Solaris to AIX

Solaris to HP-UX

HP Solaris-to-HP-UX Porting Kit

Porting Solaris code onto Itanium HP-UX 11i and Red Hat.

HP to AIX

HP to AIX migration - Network Tuning parameters - Toolbox for IT ...

HP Simplifies Migration for Sun Solaris Customers to More ...

Migrating from Solaris to HP-UX—components

Computerworld > HP's blue light special- 85% off HP-UX with ...

HP-UX to Solaris

HP-UX to Solaris Migration


Last modified: December 17, 2016