autoconf: Special Shell Variables
1
1 11.12 Special Shell Variables
1 =============================
1
1 Some shell variables should not be used, since they can have a deep
1 influence on the behavior of the shell. In order to recover a sane
1 behavior from the shell, some variables should be unset; M4sh takes
1 care of this and provides fallback values, whenever needed, to cater
11 for a very old `/bin/sh' that does not support `unset'. (⇒
Portable Shell Programming Portable Shell.).
1
1 As a general rule, shell variable names containing a lower-case
1 letter are safe; you can define and use these variables without
1 worrying about their effect on the underlying system, and without
1 worrying about whether the shell changes them unexpectedly. (The
1 exception is the shell variable `status', as described below.)
1
1 Here is a list of names that are known to cause trouble. This list
1 is not exhaustive, but you should be safe if you avoid the name
1 `status' and names containing only upper-case letters and underscores.
1
1 `?'
11 Not all shells correctly reset `$?' after conditionals (⇒
Limitations of Shell Builtins if.). Not all shells manage `$?'
1 correctly in shell functions (⇒Shell Functions) or in traps
1 (⇒Limitations of Shell Builtins trap.). Not all shells reset
1 `$?' to zero after an empty command.
1
1 $ bash -c 'false; $empty; echo $?'
1 0
1 $ zsh -c 'false; $empty; echo $?'
1 1
1
1 `_'
1 Many shells reserve `$_' for various purposes, e.g., the name of
1 the last command executed.
1
1 `BIN_SH'
1 In Tru64, if `BIN_SH' is set to `xpg4', subsidiary invocations of
1 the standard shell conform to Posix.
1
1 `CDPATH'
1 When this variable is set it specifies a list of directories to
1 search when invoking `cd' with a relative file name that did not
1 start with `./' or `../'. Posix 1003.1-2001 says that if a
1 nonempty directory name from `CDPATH' is used successfully, `cd'
1 prints the resulting absolute file name. Unfortunately this
1 output can break idioms like `abs=`cd src && pwd`' because `abs'
1 receives the name twice. Also, many shells do not conform to this
1 part of Posix; for example, `zsh' prints the result only if a
1 directory name other than `.' was chosen from `CDPATH'.
1
1 In practice the shells that have this problem also support
1 `unset', so you can work around the problem as follows:
1
1 (unset CDPATH) >/dev/null 2>&1 && unset CDPATH
1
1 You can also avoid output by ensuring that your directory name is
1 absolute or anchored at `./', as in `abs=`cd ./src && pwd`'.
1
1 Configure scripts use M4sh, which automatically unsets `CDPATH' if
1 possible, so you need not worry about this problem in those
1 scripts.
1
1 `CLICOLOR_FORCE'
1 When this variable is set, some implementations of tools like `ls'
1 attempt to add color to their output via terminal escape
1 sequences, even when the output is not directed to a terminal, and
1 can thus cause spurious failures in scripts. Configure scripts
1 use M4sh, which automatically unsets this variable.
1
1 `DUALCASE'
1 In the MKS shell, case statements and file name generation are
1 case-insensitive unless `DUALCASE' is nonzero. Autoconf-generated
1 scripts export this variable when they start up.
1
1 `ENV'
1 `MAIL'
1 `MAILPATH'
1 `PS1'
1 `PS2'
1 `PS4'
1 These variables should not matter for shell scripts, since they are
1 supposed to affect only interactive shells. However, at least one
1 shell (the pre-3.0 UWIN Korn shell) gets confused about whether it
1 is interactive, which means that (for example) a `PS1' with a side
1 effect can unexpectedly modify `$?'. To work around this bug,
1 M4sh scripts (including `configure' scripts) do something like
1 this:
1
1 (unset ENV) >/dev/null 2>&1 && unset ENV MAIL MAILPATH
1 PS1='$ '
1 PS2='> '
1 PS4='+ '
1
1 (actually, there is some complication due to bugs in `unset';
1 ⇒Limitations of Shell Builtins unset.).
1
1 `FPATH'
1 The Korn shell uses `FPATH' to find shell functions, so avoid
1 `FPATH' in portable scripts. `FPATH' is consulted after `PATH',
1 but you still need to be wary of tests that use `PATH' to find
1 whether a command exists, since they might report the wrong result
1 if `FPATH' is also set.
1
1 `GREP_OPTIONS'
1 When this variable is set, some implementations of `grep' honor
1 these options, even if the options include direction to enable
1 colored output via terminal escape sequences, and the result can
1 cause spurious failures when the output is not directed to a
1 terminal. Configure scripts use M4sh, which automatically unsets
1 this variable.
1
1 `IFS'
1 Long ago, shell scripts inherited `IFS' from the environment, but
1 this caused many problems so modern shells ignore any environment
1 settings for `IFS'.
1
1 Don't set the first character of `IFS' to backslash. Indeed,
1 Bourne shells use the first character (backslash) when joining the
1 components in `"$@"' and some shells then reinterpret (!) the
1 backslash escapes, so you can end up with backspace and other
1 strange characters.
1
1 The proper value for `IFS' (in regular code, not when performing
1 splits) is `<SPC><TAB><RET>'. The first character is especially
1 important, as it is used to join the arguments in `$*'; however,
1 note that traditional shells, but also bash-2.04, fail to adhere
1 to this and join with a space anyway.
1
1 M4sh guarantees that `IFS' will have the default value at the
1 beginning of a script, and many macros within autoconf rely on this
1 setting. It is okay to use blocks of shell code that temporarily
1 change the value of `IFS' in order to split on another character,
1 but remember to restore it before expanding further macros.
1
1 Unsetting `IFS' instead of resetting it to the default sequence is
1 not suggested, since code that tries to save and restore the
1 variable's value will incorrectly reset it to an empty value, thus
1 disabling field splitting:
1
1 unset IFS
1 # default separators used for field splitting
1
1 save_IFS=$IFS
1 IFS=:
1 # ...
1 IFS=$save_IFS
1 # no field splitting performed
1
1 `LANG'
1 `LC_ALL'
1 `LC_COLLATE'
1 `LC_CTYPE'
1 `LC_MESSAGES'
1 `LC_MONETARY'
1 `LC_NUMERIC'
1 `LC_TIME'
1 You should set all these variables to `C' because so much
1 configuration code assumes the C locale and Posix requires that
1 locale environment variables be set to `C' if the C locale is
1 desired; `configure' scripts and M4sh do that for you. Export
1 these variables after setting them.
1
1 `LANGUAGE'
1 `LANGUAGE' is not specified by Posix, but it is a GNU extension
1 that overrides `LC_ALL' in some cases, so you (or M4sh) should set
1 it too.
1
1 `LC_ADDRESS'
1 `LC_IDENTIFICATION'
1 `LC_MEASUREMENT'
1 `LC_NAME'
1 `LC_PAPER'
1 `LC_TELEPHONE'
1 These locale environment variables are GNU extensions. They are
1 treated like their Posix brethren (`LC_COLLATE', etc.) as
1 described above.
1
1 `LINENO'
1 Most modern shells provide the current line number in `LINENO'.
1 Its value is the line number of the beginning of the current
1 command. M4sh, and hence Autoconf, attempts to execute
1 `configure' with a shell that supports `LINENO'. If no such shell
1 is available, it attempts to implement `LINENO' with a Sed prepass
1 that replaces each instance of the string `$LINENO' (not followed
1 by an alphanumeric character) with the line's number. In M4sh
1 scripts you should execute `AS_LINENO_PREPARE' so that these
1 workarounds are included in your script; configure scripts do this
1 automatically in `AC_INIT'.
1
1 You should not rely on `LINENO' within `eval' or shell functions,
1 as the behavior differs in practice. The presence of a quoted
1 newline within simple commands can alter which line number is used
1 as the starting point for `$LINENO' substitutions within that
1 command. Also, the possibility of the Sed prepass means that you
1 should not rely on `$LINENO' when quoted, when in here-documents,
1 or when line continuations are used. Subshells should be OK,
1 though. In the following example, lines 1, 9, and 14 are
1 portable, but the other instances of `$LINENO' do not have
1 deterministic values:
1
1 $ cat lineno
1 echo 1. $LINENO
1 echo "2. $LINENO
1 3. $LINENO"
1 cat <<EOF
1 5. $LINENO
1 6. $LINENO
1 7. \$LINENO
1 EOF
1 ( echo 9. $LINENO )
1 eval 'echo 10. $LINENO'
1 eval 'echo 11. $LINENO
1 echo 12. $LINENO'
1 echo 13. '$LINENO'
1 echo 14. $LINENO '
1 15.' $LINENO
1 f () { echo $1 $LINENO;
1 echo $1 $LINENO }
1 f 18.
1 echo 19. \
1 $LINENO
1 $ bash-3.2 ./lineno
1 1. 1
1 2. 3
1 3. 3
1 5. 4
1 6. 4
1 7. $LINENO
1 9. 9
1 10. 10
1 11. 12
1 12. 13
1 13. $LINENO
1 14. 14
1 15. 14
1 18. 16
1 18. 17
1 19. 19
1 $ zsh-4.3.4 ./lineno
1 1. 1
1 2. 2
1 3. 2
1 5. 4
1 6. 4
1 7. $LINENO
1 9. 9
1 10. 1
1 11. 1
1 12. 2
1 13. $LINENO
1 14. 14
1 15. 14
1 18. 0
1 18. 1
1 19. 19
1 $ pdksh-5.2.14 ./lineno
1 1. 1
1 2. 2
1 3. 2
1 5. 4
1 6. 4
1 7. $LINENO
1 9. 9
1 10. 0
1 11. 0
1 12. 0
1 13. $LINENO
1 14. 14
1 15. 14
1 18. 16
1 18. 17
1 19. 19
1 $ sed '=' <lineno |
1 > sed '
1 > N
1 > s,$,-,
1 > t loop
1 > :loop
1 > s,^\([0-9]*\)\(.*\)[$]LINENO\([^a-zA-Z0-9_]\),\1\2\1\3,
1 > t loop
1 > s,-$,,
1 > s,^[0-9]*\n,,
1 > ' |
1 > sh
1 1. 1
1 2. 2
1 3. 3
1 5. 5
1 6. 6
1 7. \7
1 9. 9
1 10. 10
1 11. 11
1 12. 12
1 13. 13
1 14. 14
1 15. 15
1 18. 16
1 18. 17
1 19. 20
1
1 In particular, note that `config.status' (and any other subsidiary
1 script created by `AS_INIT_GENERATED') might report line numbers
1 relative to the parent script as a result of the potential Sed
1 pass.
1
1 `NULLCMD'
1 When executing the command `>foo', `zsh' executes `$NULLCMD >foo'
1 unless it is operating in Bourne shell compatibility mode and the
1 `zsh' version is newer than 3.1.6-dev-18. If you are using an
1 older `zsh' and forget to set `NULLCMD', your script might be
1 suspended waiting for data on its standard input.
1
1 `options'
1 For `zsh' 4.3.10, `options' is treated as an associative array
1 even after `emulate sh', so it should not be used.
1
1 `PATH_SEPARATOR'
1 On DJGPP systems, the `PATH_SEPARATOR' environment variable can be
1 set to either `:' or `;' to control the path separator Bash uses
1 to set up certain environment variables (such as `PATH'). You can
1 set this variable to `;' if you want `configure' to use `;' as a
1 separator; this might be useful if you plan to use non-Posix
1 shells to execute files. ⇒File System Conventions, for
1 more information about `PATH_SEPARATOR'.
1
1 `POSIXLY_CORRECT'
1 In the GNU environment, exporting `POSIXLY_CORRECT' with any value
1 (even empty) causes programs to try harder to conform to Posix.
1 Autoconf does not directly manipulate this variable, but `bash'
1 ties the shell variable `POSIXLY_CORRECT' to whether the script is
1 running in Posix mode. Therefore, take care when exporting or
1 unsetting this variable, so as not to change whether `bash' is in
1 Posix mode.
1
1 $ bash --posix -c 'set -o | grep posix
1 > unset POSIXLY_CORRECT
1 > set -o | grep posix'
1 posix on
1 posix off
1
1 `PWD'
1 Posix 1003.1-2001 requires that `cd' and `pwd' must update the
1 `PWD' environment variable to point to the logical name of the
1 current directory, but traditional shells do not support this.
1 This can cause confusion if one shell instance maintains `PWD' but
1 a subsidiary and different shell does not know about `PWD' and
1 executes `cd'; in this case `PWD' points to the wrong directory.
1 Use ``pwd`' rather than `$PWD'.
1
1 `RANDOM'
1 Many shells provide `RANDOM', a variable that returns a different
1 integer each time it is used. Most of the time, its value does not
1 change when it is not used, but on IRIX 6.5 the value changes all
1 the time. This can be observed by using `set'. It is common
1 practice to use `$RANDOM' as part of a file name, but code
1 shouldn't rely on `$RANDOM' expanding to a nonempty string.
1
1 `status'
1 This variable is an alias to `$?' for `zsh' (at least 3.1.6),
1 hence read-only. Do not use it.
1