4.4. Special Variable Types

In a more general context, each process has an
"environment", that is, a group of
variables that the process may reference. In this sense,
the shell behaves like any other process.

Every time a shell starts, it creates shell variables that
correspond to its own environmental variables. Updating
or adding new environmental variables causes the
shell to update its environment, and all the shell's
child processes (the commands it
executes) inherit this environment.

The space allotted to the environment is limited.
Creating too many environmental variables or ones that use up
excessive space may cause problems.

(Thank you, Stéphane Chazelas for the clarification,
and for providing the above example.)

If a script sets environmental variables, they need to be
"exported," that is, reported to the
environment local to
the script. This is the function of the export command.

A script can export variables only
to child processes,
that is, only to commands or processes which that
particular script initiates. A script invoked from
the command-line cannot
export variables back to the command-line environment.
Child processes
cannot export variables back to the parent processes that
spawned them.

Definition:
A child process is a
subprocess launched by another process, its parent.

Some scripts can perform different operations,
depending on which name they are invoked with. For this
to work, the script needs to check $0,
the name it was invoked by. There must also exist symbolic
links to all the alternate names of the script. See Example 15-2.

If a script expects a command-line parameter
but is invoked without one, this may cause a null
variable assignment, generally an undesirable
result. One way to prevent this is to append an extra
character to both sides of the assignment statement using
the expected positional parameter.

1 variable1_=$1_ # Rather than variable1=$1
2 # This will prevent an error, even if positional parameter is absent.
3
4 critical_argument01=$variable1_
5
6 # The extra character can be stripped off later, like so.
7 variable1=${variable1_/_/}
8 # Side effects only if $variable1_ begins with an underscore.
9 # This uses one of the parameter substitution templates discussed later.
10 # (Leaving out the replacement pattern results in a deletion.)
11
12 # A more straightforward way of dealing with this is
13 #+ to simply test whether expected positional parameters have been passed.
14 if [ -z $1 ]
15 then
16 exit $E_MISSING_POS_PARAM
17 fi
18
19
20 # However, as Fabian Kreutz points out,
21 #+ the above method may have unexpected side-effects.
22 # A better method is parameter substitution:
23 # ${1:-$DefaultVal}
24 # See the "Parameter Substition" section
25 #+ in the "Variables Revisited" chapter.

The shift command reassigns the positional
parameters, in effect shifting them to the left one notch.

$1 <--- $2, $2 <--- $3, $3 <--- $4, etc.

The old $1 disappears, but
$0 (the script name)
does not change. If you use a large number of
positional parameters to a script, shift
lets you access those past 10, although
{bracket} notation
also permits this.