3.28. Gotchas

	Turandot: Gli enigmi sono tre, la morte una! Caleph: No, no! Gli enigmi sono tre, una la vita!
	Puccini

Assigning reserved words or characters to variable names.

var1=case
# Causes problems.
var2=23skidoo
# Also problems. Variable names starting with a digit are reserved by the shell.
# Try var2=_23skidoo. Starting variables with an underscore is o.k.
var3=xyz((!*
# Causes even worse problems.

Using a hyphen or other reserved characters in a variable name.

var-1=23
# Use 'var_1' instead.

Using white space inappropriately (in contrast to other programming languages bash can be finicky about white space).

var1 = 23
# 'var1=23' is correct.
let c = $a - $b
# 'let c=$a-$b' or 'let "c = $a - $b"' are correct.
if [ $a -le 5]
# 'if [ $a -le 5 ]' is correct.

Using uninitialized variables (that is, using variables before a value is assigned to them). An uninitialized variable has a value of "null", not zero.

Mixing up = and -eq in a test. Remember, = is for comparing literal variables and -eq is for numbers.

	if [ $a = 273 ] # Wrong!
	if [ $a -eq 273 ] # Correct.

Sometimes variables within "test" brackets ([ ]) need to be quoted (double quotes). Failure to do so may cause unexpected behavior. See Example 3-13, Example 3-73, and Example 3-17.

Commands issued from a script may fail to execute because the script owner lacks execute permission for them. If a user cannot invoke a command from the command line, then putting it into a script will likewise fail. Try changing the attributes of the command in question, perhaps setting the suid bit (as root, of course).

Using bash version 2 functionality (see below) in a script headed with #!/bin/bash may cause a bailout with error messages. Your system may still have an older version of bash as the default installation (echo $BASH_VERSION). Try changing the header of the script to #!/bin/bash2.

A script may not export variables back to its parent process, the shell, or to the environment. Just as we learned in biology, a child process can inherit from a parent, but not vice versa.

WHATEVER=/home/bozo
export WHATEVER
exit 0

bash$ echo $WHATEVER

bash$

Sure enough, back at the command prompt, $WHATEVER remains unset.

Making scripts "suid" is generally a bad idea, as it may compromise system security. Administrative scripts should be run by root, not regular users.

Using shell scripts for CGI programming may be problematic. Shell script variables are not "typesafe", and this can cause undesirable behavior as far as CGI is concerned. Moreover, it is difficult to "hacker-proof" shell scripts.