3.30. Gotchas

Assigning reserved words or characters to variable names.

   1 case=value0
   2 # Causes problems.
   3 23skidoo=value1
   4 # Also problems. Variable names starting with a digit are reserved by the shell.
   5 # Try _23skidoo=value1. Starting variables with an underscore is o.k.
   6 xyz((!*=value2
   7 # Causes even worse problems.

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

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

Using whitespace inappropriately (in contrast to other programming languages, Bash can be quite finicky about whitespace).

   1 var1 = 23   # 'var1=23' is correct.
   2 # On line above, Bash attempts to execute command "var1"
   3 # with the arguments "=" and "23".
   4 	
   5 let c = $a - $b   # 'let c=$a-$b' or 'let "c = $a - $b"' are correct.
   6 
   7 if [ $a -le 5]    # if [ $a -le 5 ]   is correct.
   8 # if [ "$a" -le 5 ]   is even better.
   9 # [[ $a -le 5 ]] also works.

Assuming uninitialized variables (variables before a value is assigned to them) are "zeroed out". 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 for integers.

   1 if [ "$a" = 273 ]      # Is $a an integer or string?
   2 if [ "$a" -eq 273 ]    # If $a is an integer.
   3 
   4 # Sometimes you can mix up -eq and = without adverse consequences.
   5 # However...
   6 
   7 
   8 a=273.0   # Not an integer.
   9 	   
  10 if [ "$a" = 273 ]
  11 then
  12   echo "Comparison works."
  13 else  
  14   echo "Comparison does not work."
  15 fi    # Comparison does not work.
  16 
  17 # Same with   a=" 273"  and a="0273".
  18 
  19 
  20 # Likewise, problems trying to use "-eq" with non-integer values.
  21 	   
  22 if [ "$a" -eq 273.0 ]
  23 then
  24   echo "a = $a'
  25 fi  # Aborts with an error message.  
  26 # test.sh: [: 273.0: integer expression expected

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

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 even setting the suid bit (as root, of course).

Attempting to use - as a redirection operator (which it is not) will usually result in an unpleasant surprise.

   1 command1 2> - | command2  # Trying to redirect error output of command1 into a pipe...
   2 #    ...will not work.	
   3 
   4 command1 2>& - | command2  # Also futile.
   5 
   6 Thanks, S.C.

Using Bash version 2 functionality in a script headed with #!/bin/bash may cause a bailout with error messages. Older Linux machines may have version 1.x of Bash as the default installation (echo $BASH_VERSION). Try changing the header of the script to #!/bin/bash2.

Using Bash-specific functionality in a Bourne shell script (#!/bin/sh) on a non-Linux machine may cause unexpected behavior. A Linux system usually aliases sh to bash, but this does not necessarily hold true for a generic UNIX machine.

A script with DOS-type newlines (\r\n) will fail to execute, since #!/bin/bash\r\n is not recognized, not the same as the expected #!/bin/bash\n. The fix is to convert the script to UNIX-style newlines.

A shell script headed by #!/bin/sh may not run in full Bash-compatibility mode. Some Bash-specific functions might be disabled. Scripts that need complete access to all the Bash-specific extensions should start with #!/bin/bash.

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.

   1 WHATEVER=/home/bozo
   2 export WHATEVER
   3 exit 0

 bash$ echo $WHATEVER
 
 bash$ 

Setting and manipulating variables in a subshell, then attempting to use those same variables outside the scope of the subshell will result an unpleasant surprise.

   1 #!/bin/bash
   2 # Pitfalls of variables in a subshell.
   3 
   4 outer_variable=outer
   5 echo
   6 echo "outer_variable = $outer_variable"
   7 echo
   8 
   9 (
  10 # Begin subshell
  11 
  12 echo "outer_variable inside subshell = $outer_variable"
  13 inner_variable=inner  # Set
  14 echo "inner_variable inside subshell = $inner_variable"
  15 outer_variable=inner  # Will value change globally?
  16 echo "outer_variable inside subshell = $outer_variable"
  17 
  18 # End subshell
  19 )
  20 
  21 echo
  22 echo "inner_variable outside subshell = $inner_variable"  # Unset.
  23 echo "outer_variable outside subshell = $outer_variable"  # Unchanged.
  24 echo
  25 
  26 exit 0

Using "suid" commands in scripts is risky, as it may compromise system security. [1]

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.