22.2.7

back: test
forward: pattern matching
 
fastback: pattern matching
up: sh implementation
fastforward: environment
top: autoconf, automake, and libtool
contents: table of contents
index: index
about: about this document

22.2.7 $

When using shell variables in your portable scripts, you need to write them in a somewhat stylised fashion to maximise the number of shell implementations that will interpret your code as expected:

  • Convenient though it is, the POSIX `$(command parameters)' syntax for command substitution is not remotely portable. Despite it being more difficult to nest, you must use ``command parameters`' instead.
  • The most portable way to set a default value for a shell variable is:
     
     $ echo ${no_such_var-"default value"} default value 

    If there is any whitespace in the default value, as there is here, you must be careful to quote the entire value, since some shells will raise an error:

     
     $ echo ${no_such_var-default value} sh: bad substitution 
  • The unset command is not available in many of the degenerate Bourne shell implementations. Generally, it is not too difficult to get by without it, but following the logic that led to the shell script in (), it would be trivial to extend the test case for confirming a shell's suitability to include a check for unset . Although it has not been put to the test, the theory is that all the interesting machines in use today have some shell that supports unset .
  • Be religious about double quoting variable expansions. Using `"$foo"' will avoid trouble with unexpected spaces in filenames, and compression of all whitespace to a single space in unquoted variable expansions.
  • To avoid accidental interpretation of variable expansions as command options you can use the following technique:
     
     $ foo=-n $ echo $foo $ echo x"$foo"  sed -e 's/^x//' -n 
  • If it is set, IFS splits words on whitespace by default. If you change it, be sure to put it back when you're done, or the shell may behave very strangely from that point. For example, when you need to examine each element of `$PATH' in turn :
     
     # The whitespace at the end of the following line is a space # followed by literal tab and newline characters. save_IFS="${IFS=  }"; IFS=":" set dummy $PATH IFS="$save_IFS" shift 

    Alternatively, you can take advantage of the fact that command substitutions occur in a separate subshell, and do not corrupt the environment of the calling shell:

     
     set dummy `IFS=:; echo $PATH` shift 

    Strictly speaking, the `dummy' argument is required to stop the set command from interpreting the first word of the expanded backquote expression as a command option. Realistically, no one is going to have `-x' , for example, as the first element of their `PATH' variable, so the `dummy' could be omitted -- as I did earlier in the script in ().

  • Some shells expand `$@' to the empty string, even when there are no actual parameters ( `$#' is 0). If you need to replicate the parameters that were passed to the executing script, when feeding the script to a more suitable interpreter for example, you must use the following:
     
     ${1+"$@"} 

    Similarly, although all known shells do correctly use `$@' as the default argument to a for command, you must write it like this:

     
     for arg do   stuff done 

    When you rely on implicit `$@' like this, it is important to write the do keyword on a separate line. Some degenerate shells can not parse the following:

     
     for arg; do   stuff done 

This document was generated by Gary V. Vaughan on May, 24 2001 using texi2html


GNU Autoconf, Automake and Libtool
GNU Autoconf, Automake, and Libtool
ISBN: 1578701902
EAN: 2147483647
Year: 2002
Pages: 290

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net