| | 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.
Download
