Turandot: Gli enigmi sono tre, la morte una! Caleph: No, no! Gli enigmi sono tre, una la vita! --Puccini |
Here are some (non-recommended!) scripting practices that will bring excitement to an otherwise dull life.
Assigning reserved words or characters to variable names.
1 case=value0 # Causes problems. 2 23skidoo=value1 # Also problems. 3 # Variable names starting with a digit are reserved by the shell. 4 # Try _23skidoo=value1. Starting variables with an underscore is o.k. 5 6 # However . . . using just the underscore will not work. 7 _=25 8 echo $_ # $_ is a special variable set to last arg of last command. 9 10 xyz((!*=value2 # Causes severe problems. 11 # As of version 3 of Bash, periods are not allowed within variable names. |
Using a hyphen or other reserved characters in a variable name (or function name).
1 var-1=23 2 # Use 'var_1' instead. 3 4 function-whatever () # Error 5 # Use 'function_whatever ()' instead. 6 7 8 # As of version 3 of Bash, periods are not allowed within function names. 9 function.whatever () # Error 10 # Use 'functionWhatever ()' instead. |
Using the same name for a variable and a function. This can make a script difficult to understand.
1 do_something ()
2 {
3 echo "This function does something with \"$1\"."
4 }
5
6 do_something=do_something
7
8 do_something do_something
9
10 # All this is legal, but highly confusing. |
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. |
Not terminating with a semicolon the final command in a code block within curly brackets.
1 { ls -l; df; echo "Done." }
2 # bash: syntax error: unexpected end of file
3
4 { ls -l; df; echo "Done."; }
5 # ^ ### Final command needs semicolon. |
Assuming uninitialized variables (variables before a value is assigned to them) are "zeroed out". An uninitialized variable has a value of null, not zero.
1 #!/bin/bash 2 3 echo "uninitialized_var = $uninitialized_var" 4 # uninitialized_var = |
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 interchange -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 |
Misusing string comparison operators.
Example 31-1. Numerical and string comparison are not equivalent
1 #!/bin/bash 2 # bad-op.sh: Trying to use a string comparison on integers. 3 4 echo 5 number=1 6 7 # The following while-loop has two errors: 8 #+ one blatant, and the other subtle. 9 10 while [ "$number" < 5 ] # Wrong! Should be: while [ "$number" -lt 5 ] 11 do 12 echo -n "$number " 13 let "number += 1" 14 done 15 # Attempt to run this bombs with the error message: 16 #+ bad-op.sh: line 10: 5: No such file or directory 17 # Within single brackets, "<" must be escaped, 18 #+ and even then, it's still wrong for comparing integers. 19 20 echo "---------------------" 21 22 while [ "$number" \< 5 ] # 1 2 3 4 23 do # 24 echo -n "$number " # It *seems* to work, but . . . 25 let "number += 1" #+ it actually does an ASCII comparison, 26 done #+ rather than a numerical one. 27 28 echo; echo "---------------------" 29 30 # This can cause problems. For example: 31 32 lesser=5 33 greater=105 34 35 if [ "$greater" \< "$lesser" ] 36 then 37 echo "$greater is less than $lesser" 38 fi # 105 is less than 5 39 # In fact, "105" actually is less than "5" 40 #+ in a string comparison (ASCII sort order). 41 42 echo 43 44 exit 0 |
Sometimes variables within "test" brackets ([ ]) need to be quoted (double quotes). Failure to do so may cause unexpected behavior. See Example 7-6, Example 19-5, and Example 9-6.
Quoting a variable containing whitespace prevents splitting. Sometimes this produces unintended consequences.
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 2 # Trying to redirect error output of command1 into a pipe . . . 3 # . . . will not work. 4 5 command1 2>& - | command2 # Also futile. 6 7 Thanks, S.C. |
Using Bash version 2+ functionality may cause a bailout with error messages. Older Linux machines may have version 1.XX of Bash as the default installation.
1 #!/bin/bash 2 3 minimum_version=2 4 # Since Chet Ramey is constantly adding features to Bash, 5 # you may set $minimum_version to 2.XX, 3.XX, or whatever is appropriate. 6 E_BAD_VERSION=80 7 8 if [ "$BASH_VERSION" \< "$minimum_version" ] 9 then 10 echo "This script works only with Bash, version $minimum or greater." 11 echo "Upgrade strongly recommended." 12 exit $E_BAD_VERSION 13 fi 14 15 ... |
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.
Using undocumented features in Bash turns out to be a dangerous practice. In previous releases of this book there were several scripts that depended on the "feature" that, although the maximum value of an exit or return value was 255, that limit did not apply to negative integers. Unfortunately, in version 2.05b and later, that loophole disappeared. See Example 23-9.
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.
1 #!/bin/bash 2 3 echo "Here" 4 5 unix2dos $0 # Script changes itself to DOS format. 6 chmod 755 $0 # Change back to execute permission. 7 # The 'unix2dos' command removes execute permission. 8 9 ./$0 # Script tries to run itself again. 10 # But it won't work as a DOS file. 11 12 echo "There" 13 14 exit 0 |
A shell script headed by #!/bin/sh will 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.
Putting whitespace in front of the terminating limit string of a here document will cause unexpected behavior in a script.
Putting more than one echo statement in a function whose output is captured.
1 add2 ()
2 {
3 echo "Whatever ... " # Delete this line!
4 let "retval = $1 + $2"
5 echo $retval
6 }
7
8 num1=12
9 num2=43
10 echo "Sum of $num1 and $num2 = $(add2 $num1 $num2)"
11
12 # Sum of 12 and 43 = Whatever ...
13 # 55
14
15 # The "echoes" concatenate. |
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$ |
Sure enough, back at the command prompt, $WHATEVER remains unset.
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.
Example 31-2. Subshell Pitfalls
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 # Will 'exporting' make a difference? 19 # export inner_variable 20 # export outer_variable 21 # Try it and see. 22 23 # End subshell 24 ) 25 26 echo 27 echo "inner_variable outside subshell = $inner_variable" # Unset. 28 echo "outer_variable outside subshell = $outer_variable" # Unchanged. 29 echo 30 31 exit 0 32 33 # What happens if you uncomment lines 19 and 20? 34 # Does it make a difference? |
Piping echo output to a read may produce unexpected results. In this scenario, the read acts as if it were running in a subshell. Instead, use the set command (as in Example 14-18).
Example 31-3. Piping the output of echo to a read
1 #!/bin/bash 2 # badread.sh: 3 # Attempting to use 'echo and 'read' 4 #+ to assign variables non-interactively. 5 6 a=aaa 7 b=bbb 8 c=ccc 9 10 echo "one two three" | read a b c 11 # Try to reassign a, b, and c. 12 13 echo 14 echo "a = $a" # a = aaa 15 echo "b = $b" # b = bbb 16 echo "c = $c" # c = ccc 17 # Reassignment failed. 18 19 # ------------------------------ 20 21 # Try the following alternative. 22 23 var=`echo "one two three"` 24 set -- $var 25 a=$1; b=$2; c=$3 26 27 echo "-------" 28 echo "a = $a" # a = one 29 echo "b = $b" # b = two 30 echo "c = $c" # c = three 31 # Reassignment succeeded. 32 33 # ------------------------------ 34 35 # Note also that an echo to a 'read' works within a subshell. 36 # However, the value of the variable changes *only* within the subshell. 37 38 a=aaa # Starting all over again. 39 b=bbb 40 c=ccc 41 42 echo; echo 43 echo "one two three" | ( read a b c; 44 echo "Inside subshell: "; echo "a = $a"; echo "b = $b"; echo "c = $c" ) 45 # a = one 46 # b = two 47 # c = three 48 echo "-----------------" 49 echo "Outside subshell: " 50 echo "a = $a" # a = aaa 51 echo "b = $b" # b = bbb 52 echo "c = $c" # c = ccc 53 echo 54 55 exit 0 |
In fact, as Anthony Richardson points out, piping to any loop can cause a similar problem.
1 # Loop piping troubles.
2 # This example by Anthony Richardson,
3 #+ with addendum by Wilbert Berendsen.
4
5
6 foundone=false
7 find $HOME -type f -atime +30 -size 100k |
8 while true
9 do
10 read f
11 echo "$f is over 100KB and has not been accessed in over 30 days"
12 echo "Consider moving the file to archives."
13 foundone=true
14 # ------------------------------------
15 echo "Subshell level = $BASH_SUBSHELL"
16 # Subshell level = 1
17 # Yes, we're inside a subshell.
18 # ------------------------------------
19 done
20
21 # foundone will always be false here since it is
22 #+ set to true inside a subshell
23 if [ $foundone = false ]
24 then
25 echo "No files need archiving."
26 fi
27
28 # =====================Now, here is the correct way:=================
29
30 foundone=false
31 for f in $(find $HOME -type f -atime +30 -size 100k) # No pipe here.
32 do
33 echo "$f is over 100KB and has not been accessed in over 30 days"
34 echo "Consider moving the file to archives."
35 foundone=true
36 done
37
38 if [ $foundone = false ]
39 then
40 echo "No files need archiving."
41 fi
42
43 # ==================And here is another alternative==================
44
45 # Places the part of the script that reads the variables
46 #+ within a code block, so they share the same subshell.
47 # Thank you, W.B.
48
49 find $HOME -type f -atime +30 -size 100k | {
50 foundone=false
51 while read f
52 do
53 echo "$f is over 100KB and has not been accessed in over 30 days"
54 echo "Consider moving the file to archives."
55 foundone=true
56 done
57
58 if ! $foundone
59 then
60 echo "No files need archiving."
61 fi
62 } |
A related problem occurs when trying to write the stdout of a tail -f piped to grep.
1 tail -f /var/log/messages | grep "$ERROR_MSG" >> error.log 2 # The "error.log" file will not have anything written to it. |
Using "suid" commands within 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 "cracker-proof" shell scripts.
Bash does not handle the double slash (//) string correctly.
Bash scripts written for Linux or BSD systems may need fixups to run on a commercial UNIX (or Apple OSX) machine. Such scripts often employ the GNU set of commands and filters, which have greater functionality than their generic UNIX counterparts. This is particularly true of such text processing utilites as tr.
Danger is near thee -- Beware, beware, beware, beware. Many brave hearts are asleep in the deep. So beware -- Beware. --A.J. Lamb and H.W. Petrie |
| [1] | Setting the suid permission on the script itself has no effect in Linux and most other UNIX flavors. |