Some shell variables should not be used, since they can have a deep influence on the behavior of the shell. In order to recover a sane behavior from the shell, some variables should be unset; M4sh takes care of this and provides fallback values, whenever needed, to cater for a very old /bin/sh that does not support unset. (see Portable Shell Programming).
As a general rule, shell variable names containing a lower-case letter
are safe; you can define and use these variables without worrying about
their effect on the underlying system, and without worrying about
whether the shell changes them unexpectedly. (The exception is the
shell variable status, as described below.)
Here is a list of names that are known to cause trouble. This list is
not exhaustive, but you should be safe if you avoid the name
status and names containing only upper-case letters and
underscores.
? $ bash -c 'false; $empty; echo $?'
0
$ zsh -c 'false; $empty; echo $?'
1
_BIN_SHxpg4, subsidiary invocations of
the standard shell conform to Posix.
CDPATHcd with a relative file name that did not start
with ‘./’ or ‘../’. Posix
1003.1-2001 says that if a nonempty directory name from CDPATH
is used successfully, cd prints the resulting absolute
file name. Unfortunately this output can break idioms like
‘abs=`cd src && pwd`’ because abs receives the name twice.
Also, many shells do not conform to this part of Posix; for
example, zsh prints the result only if a directory name
other than . was chosen from CDPATH.
In practice the shells that have this problem also support unset, so you can work around the problem as follows:
(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
You can also avoid output by ensuring that your directory name is absolute or anchored at ‘./’, as in ‘abs=`cd ./src && pwd`’.
Configure scripts use M4sh, which automatically unsets CDPATH if
possible, so you need not worry about this problem in those scripts.
CLICOLOR_FORCEDUALCASEENVMAILMAILPATHPS1PS2PS4 (unset ENV) >/dev/null 2>&1 && unset ENV MAIL MAILPATH
PS1='$ '
PS2='> '
PS4='+ '
(actually, there is some complication due to bugs in unset;
see see Limitations of Shell Builtins).
FPATHGREP_OPTIONSIFSDon't set the first character of IFS to backslash. Indeed, Bourne shells use the first character (backslash) when joining the components in ‘"$@"’ and some shells then reinterpret (!) the backslash escapes, so you can end up with backspace and other strange characters.
The proper value for IFS (in regular code, not when performing splits) is ‘<SPC><TAB><RET>’. The first character is especially important, as it is used to join the arguments in ‘$*’; however, note that traditional shells, but also bash-2.04, fail to adhere to this and join with a space anyway.
M4sh guarantees that IFS will have the default value at the beginning of a script, and many macros within autoconf rely on this setting. It is okay to use blocks of shell code that temporarily change the value of IFS in order to split on another character, but remember to restore it before expanding further macros.
Unsetting IFS instead of resetting it to the default sequence
is not suggested, since code that tries to save and restore the
variable's value will incorrectly reset it to an empty value, thus
disabling field splitting:
unset IFS
# default separators used for field splitting
save_IFS=$IFS
IFS=:
# ...
IFS=$save_IFS
# no field splitting performed
LANGLC_ALLLC_COLLATELC_CTYPELC_MESSAGESLC_MONETARYLC_NUMERICLC_TIMELANGUAGELC_ADDRESSLC_IDENTIFICATIONLC_MEASUREMENTLC_NAMELC_PAPERLC_TELEPHONELINENOLINENO.
Its value is the line number of the beginning of the current command.
M4sh, and hence Autoconf, attempts to execute configure with
a shell that supports LINENO. If no such shell is available, it
attempts to implement LINENO with a Sed prepass that replaces each
instance of the string $LINENO (not followed by an alphanumeric
character) with the line's number. In M4sh scripts you should execute
AS_LINENO_PREPARE so that these workarounds are included in
your script; configure scripts do this automatically in AC_INIT.
You should not rely on LINENO within eval or shell
functions, as the behavior differs in practice. The presence of a
quoted newline within simple commands can alter which line number is
used as the starting point for $LINENO substitutions within that
command. Also, the possibility of the Sed prepass means that you should
not rely on $LINENO when quoted, when in here-documents, or when
line continuations are used. Subshells should be OK, though. In the
following example, lines 1, 9, and 14 are portable, but the other
instances of $LINENO do not have deterministic values:
$ cat lineno
echo 1. $LINENO
echo "2. $LINENO
3. $LINENO"
cat <<EOF
5. $LINENO
6. $LINENO
7. \$LINENO
EOF
( echo 9. $LINENO )
eval 'echo 10. $LINENO'
eval 'echo 11. $LINENO
echo 12. $LINENO'
echo 13. '$LINENO'
echo 14. $LINENO '
15.' $LINENO
f () { echo $1 $LINENO;
echo $1 $LINENO }
f 18.
echo 19. \
$LINENO
$ bash-3.2 ./lineno
1. 1
2. 3
3. 3
5. 4
6. 4
7. $LINENO
9. 9
10. 10
11. 12
12. 13
13. $LINENO
14. 14
15. 14
18. 16
18. 17
19. 19
$ zsh-4.3.4 ./lineno
1. 1
2. 2
3. 2
5. 4
6. 4
7. $LINENO
9. 9
10. 1
11. 1
12. 2
13. $LINENO
14. 14
15. 14
18. 0
18. 1
19. 19
$ pdksh-5.2.14 ./lineno
1. 1
2. 2
3. 2
5. 4
6. 4
7. $LINENO
9. 9
10. 0
11. 0
12. 0
13. $LINENO
14. 14
15. 14
18. 16
18. 17
19. 19
$ sed '=' <lineno |
> sed '
> N
> s,$,-,
> t loop
> :loop
> s,^\([0-9]*\)\(.*\)[$]LINENO\([^a-zA-Z0-9_]\),\1\2\1\3,
> t loop
> s,-$,,
> s,^[0-9]*\n,,
> ' |
> sh
1. 1
2. 2
3. 3
5. 5
6. 6
7. \7
9. 9
10. 10
11. 11
12. 12
13. 13
14. 14
15. 15
18. 16
18. 17
19. 20
In particular, note that config.status (and any other subsidiary
script created by AS_INIT_GENERATED) might report line numbers
relative to the parent script as a result of the potential Sed pass.
NULLCMDPATH_SEPARATORPATH_SEPARATOR.
PWDRANDOMRANDOM, a variable that returns a different
integer each time it is used. Most of the time, its value does not
change when it is not used, but on IRIX 6.5 the value changes all
the time. This can be observed by using set. It is common
practice to use $RANDOM as part of a file name, but code
shouldn't rely on $RANDOM expanding to a nonempty string.
statuszsh (at least 3.1.6),
hence read-only. Do not use it.