|In the first part of this series, we examined how to create a quick shell script, and how rapidly prototype a script for use. In the second part of this series we will focus on variables, special variables and input redirection.|
Variables. Simple enough, and a concept that most administrators are familiar with. How are they used in Bash? Values are set with a simple assignment. An example:
The variable a has now been set to the value myvalue. Really simple, right? It is, but there is a very important caveat. In bash, variables are untyped. Huh? bash treats all variables the same, as a string. It has no concept of the type of data stored in the variable value. In practical terms, bash does not know the difference between and integer and a string. Does this mean that variables cannot use operations or comparisons? No, but it does mean that the script writer has to keep track of the type of variable, because bash will not do it for you.
Retrieving the value of a variable is straightforward as well, prefix the variable name with a $ sign. Returning to our example briefly. If a is assigned myvalue, it can be retrieved with:
myvalue is returned when typing this command.
Bash also uses a number of special variables. In this part of the series, we will only examine two of variable types.
What is an environment variable? It is a variable invoked every time a new shell is invoked. Though not stated, in the previous part of this series an environment variable was used: PATH. There are a number of variables which can also be leveraged in a script. Two of the most notable variables that can be used are HOME and USER. Each of these values makes any script more portable. Quick example:
chmod u+x $HOME/Documents/somefile
Note the use of the HOME variable. With the use of this variable, the script can be leveraged across the entire system.
Shell variables are variables that are used internally by bash. A complete listing of them can be found in the bash manual page. We'll look at some of the more interesting shell variables later in this series. For now, let's move on to input redirection.
The first special file that can be used with input redirection is /dev/null. It is often referred to as the "bit bucket". It takes the output of any command and writes it to the special block device, always returning a successful write. In practice, it is used when the output of a command is not important. Here's a quick example:
rm -rf /cores/* > /dev/null
This command removes every file listed in the cores directory, and does not echo any output. This type of redirection is commonly used in cron jobs.
The second file that is often used with input redirection is /dev/tty. This file is useful when input cannot be provided by a program, and must come from interactive entry. An example may illustrate its usage:
read pass < /dev/tty
Note how the variable pass is read from using input redirection from the /dev/tty file.
A couple of other quick notes about redirection. What if one wants to redirect standard input, output or error? Here is an example of the most common use of input/output redirection:
What does this command do? It combines both standard error and standard output into a single stream. Again, a simple example:
ls -RZ * >> command.log 2>&1
Try typing this command. What happens? What should happen is that a file is written, command.log, which contains both standard error and standard input. In the above example, the file contains this information:
ls: illegal option -- Z
usage: ls [-ABCFGHLPRSTWZabcdefghiklmnopqrstuwx1] [file ...]
Note how the standard error input is contained in the file. An important warning though, the shell processes redirections left to right. Try the above example, but reverse the order of redirection, so:
ls -RZ * 2>&1 >> command.log
Now what happens? Standard error is redirected to standard input before it is output to the file. therefore it writes no information to the command.log file.
Next time, it's time to delve into testing, using comparision and if/then constructs.