Environment

In addition to the problems with portability in shell implementations discussed in the previous section, the behaviour of the shell can also be drastically affected by the contents of certain environment variables, and the operating environment provided by the host machine.

It is important to be aware of the behavior of some of the operating systems within which your shell script might run. Although not directly related to the implementation of the shell interpreter, the characteristics of some of target architectures do influence what is considered to be portable. To ensure your script will work on as many shell implementations as possible, you must observe the followin points.

SCO Unix doesn't like LANG=C and friends, but without LC_MESSAGES=C, Solaris will translate variable values in set! Similarly, without LC_CTYPE=C, compiled C code can behave unexpectedly. The trick is to set the values to C, except for if they are not already set at all:

for var in LANG LC_ALL LC_MESSAGES LC_CTYPES LANGUAGES do if eval test x"\${$var+set}" = xset; then eval $var=C; eval export $var fi done

HP-UX ksh and all POSIX shells print the target directory to standard output if CDPATH is set.

if test x"${CDPATH+set}" = xset; then CDPATH=:; export CDPATH; fi

The target architecture file system may impose limits on your scripts. IF you want your scripts to run on the architectures which impose these limits, then your script must adhere to these limits:

• The ISO9660 filesystem, as used on most CD-ROMs, limits nesting of directories to a maximum depth of twelve levels.

• Many old Unix filesystems place a 14 character limit on the length of any filename. If you care about portability to DOS, that has an 8 character limit with an optional extension of 3 or fewer characters (known as 8.3 notation).

A useful idiom when you need to determine whether a particular pathname is relative or absolute, which works for DOS targets to follows:

case "$file" in [\\/]* | ?:[\\/]*) echo absolute ;; *) echo default ;; esac