Chapter 6. Tips and techniques 151
This creates the variable DIRECTORY if necessary and set its value to /OrderManagement.
There are no types for variables. They are all strings, although some commands may attempt
to interpret the contents as numbers.
Names are case sensitive. The variable defined in the previous example is not the same as
Directory or directory. It is typical to use names entirely in uppercase, but this is not required.
You may reference a variable by using $ followed by its name. This is replaced by its current
contents. You can use this as a parameter to a command, part of a parameter, or even all or
part of the command name. Consider this example:
cd $DIRECTORY/log
This changes the current directory to the subdirectory log of the directory whose name was in
the variable DIRECTORY. This is similar to DOS, except that DOS would use %DIRECTORY%.
This is a typical example of use. It is common to need to refer to the directory of a product
multiple times within a large script. To avoid repeating the name and making it difficult to
change later, it is common to set the name once in a variable and then use that as required
later in the script.
If one script (the parent) executes another (the child), then the value of the variables of the
parent will not normally be available to the child. Also, if the child changes a variable, then the
change will not be seen by the parent.
If the parent uses the export command to set a variable, then it will be available to the child.
export DIRECTORY=/OrderManagement
A child script that is run later would see the variable DIRECTORY with the value set by its parent.
Nonetheless, if the child changes the variable, the parent will not see the change.
If the parent script executes the child script with the command . (dot), then the commands in
the child script will behave as if they were executed by the parent. In this case, variables set in
either way by the parent (export or not) are seen by the child and changes made by the child
are seen by the parent.
A useful feature of Qshell commands is redirection of standard output. Standard output is the
output from Qshell programs that is sent to the Qshell display. If you follow a command or
script with a > (greater than) sign and a file name, then output that would go to standard
output instead goes to that file. This can be useful for saving the output in a file as a log. It is
also useful if you are executing your script from a CL program using the QSH command and
you do not want the program to stop with a Qshell display. As mentioned earlier, if a command
is supplied to the Qshell as a parameter and it produces no output, the display is not shown
and the program proceeds without operator intervention. Redirecting output to a file is a way
to arrange that no output is produced.
myscript.sh > redirect.out
A second output stream is called standard error. This is similar to standard output and is
shown on the Qshell display by default. It is not affected by the redirection of standard output
but can be redirected in a similar way by using the operator 2> followed by a file name. The
ability to redirect error output separately can be useful. In testing, you may want to redirect
only normal output so that any error output is obvious. In production, you may want the error
output also to go to a log file. You may have errors if you attempt to redirect both standard and
error output to the same file, but you can solve this by using the unusual operator 2>&1. This
means that stream 2 (another name for standard error) should be merged with stream 1
(another name for standard output). Therefore, it is affected by the same redirection as
standard output.
