A practical guide to Fedora and Red Hat Enterprise Linux, 7th Edition (2014)

---

Combining command substitution (page 410) with the set builtin is a convenient way to alter standard output of a command to a form that can be easily manipulated in a shell script. The following script shows how to use date and set to provide the date in a useful format. The first command shows the output of date. Then cat displays the contents of the dateset script. The first command in this script uses command substitution to set the positional parameters to the output of the date utility. The next command, echo $*, displays all positional parameters resulting from the previous set. Subsequent commands display the values of $1, $2, $3, and $6. The final command displays the date in a format you can use in a letter or report.

$ date
Wed Aug 15 17:35:29 PDT 2012
$ cat dateset
set $(date)
echo $*
echo
echo "Argument 1: $1"
echo "Argument 2: $2"
echo "Argument 3: $3"
echo "Argument 6: $6"
echo
echo "$2 $3, $6"

$ ./dateset
Wed Aug 15 17:35:34 PDT 2012

Argument 1: Wed
Argument 2: Aug
Argument 3: 15
Argument 6: 2012

Aug 15, 2012

You can also use the +format argument to date to specify the content and format of its output.

set displays shell variables

When called without arguments, set displays a list of the shell variables that are set, including user-created variables and keyword variables. Under bash, this list is the same as that displayed by declare (page 357) when it is called without any arguments.

$ set
BASH_VERSION='4.2.24(1)-release'
COLORS=/etc/DIR_COLORS
COLUMNS=89
LESSOPEN='||/usr/bin/lesspipe.sh %s'
LINES=53
LOGNAME=sam
MAIL=/var/spool/mail/sam
MAILCHECK=60
...

The set builtin can also perform other tasks. For more information refer to “set: Works with Shell Features, Positional Parameters, and Variables” on page 1036.

shift: Promotes Positional Parameters

The shift builtin promotes each positional parameter. The first argument (which was represented by $1) is discarded. The second argument (which was represented by $2) becomes the first argument (now $1), the third argument becomes the second, and so on. Because no “unshift” command exists, you cannot bring back arguments that have been discarded. An optional argument to shift specifies the number of positions to shift (and the number of arguments to discard); the default is 1.

The following demo_shift script is called with three arguments. Double quotation marks around the arguments to echo preserve the spacing of the output but allow the shell to expand variables. The program displays the arguments and shifts them repeatedly until no arguments are left to shift.

$ cat demo_shift
echo "arg1= $1 arg2= $2 arg3= $3"
shift
echo "arg1= $1 arg2= $2 arg3= $3"
shift
echo "arg1= $1 arg2= $2 arg3= $3"
shift
echo "arg1= $1 arg2= $2 arg3= $3"
shift

$ ./demo_shift alice helen zach
arg1= alice arg2= helen arg3= zach
arg1= helen arg2= zach arg3=
arg1= zach arg2= arg3=
arg1= arg2= arg3=

Repeatedly using shift is a convenient way to loop over all command-line arguments in shell scripts that expect an arbitrary number of arguments. See page 989 for a shell script that uses shift.

$* and $@: Expand to All Positional Parameters

The shell expands the $* parameter to all positional parameters, as the display_all program demonstrates:

$ cat display_all
echo All arguments are $*

$ ./display_all a b c d e f g h i j k l m n o p
All arguments are a b c d e f g h i j k l m n o p

"$*" Versus "$@"

The $* and $@ parameters work the same way except when they are enclosed within double quotation marks. Using "$*" yields a single argument with the first character in IFS (page 363; normally a SPACE) between the positional parameters. Using "$@" produces a list wherein each positional parameter is a separate argument. This difference typically makes "$@" more useful than "$*" in shell scripts.

The following scripts help explain the difference between these two parameters. In the second line of both scripts, the single quotation marks keep the shell from interpreting the enclosed special characters, allowing the shell to pass them to echo so echo can display them. The bb1 script shows that set "$*" assigns multiple arguments to the first command-line parameter.

$ cat bb1
set "$*"
echo $# parameters with '"$*"'
echo 1: $1
echo 2: $2
echo 3: $3

$ ./bb1 a b c
1 parameters with "$*"
1: a b c
2:
3:

The bb2 script shows that set "$@" assigns each argument to a different command-line parameter.

$ cat bb2
set "$@"
echo $# parameters with '"$@"'
echo 1: $1
echo 2: $2
echo 3: $3

$ ./bb2 a b c
3 parameters with "$@"
1: a
2: b
3: c

Special Parameters

Special parameters enable you to access useful values pertaining to positional parameters and the execution of shell commands. As with positional parameters, the shell expands a special parameter when it is preceded by a $. Also as with positional parameters, you cannot modify the value of a special parameter using an assignment statement.

$#: Number of Positional Parameters

The shell expands $# to the decimal number of arguments on the command line (positional parameters), not counting the name of the calling program:

$ cat num_args
echo "This script was called with $# arguments."
$ ./num_args sam max zach
This script was called with 3 arguments.

The next example shows set initializing four positional parameters and echo displaying the number of parameters set initialized:

$ set a b c d; echo $#
4

$$: PID Number

The shell expands the $$ parameter to the PID number of the process that is executing it. In the following interaction, echo displays the value of this parameter and the ps utility confirms its value. Both commands show the shell has a PID number of 5209:

$ echo $$
5209
$ ps
PID TTY TIME CMD
5209 pts/1 00:00:00 bash
6015 pts/1 00:00:00 ps

Because echo is built into the shell, the shell does not create another process when you give an echo command. However, the results are the same whether echo is a builtin or not, because the shell expands $$ before it forks a new process to run a command. Try giving this command using the echo utility (/bin/echo), which is run by another process, and see what happens.

Naming temporary files

In the following example, the shell substitutes the value of $$ and passes that value to cp as a prefix for a filename:

$ echo $$
8232
$ cp memo $$.memo
$ ls
8232.memo memo

Incorporating a PID number in a filename is useful for creating unique filenames when the meanings of the names do not matter; this technique is often used in shell scripts for creating names of temporary files. When two people are running the same shell script, having unique filenames keeps the users from inadvertently sharing the same temporary file.

The following example demonstrates that the shell creates a new shell process when it runs a shell script. The id2 script displays the PID number of the process running it (not the process that called it—the substitution for $$ is performed by the shell that is forked to run id2):

$ cat id2
echo "$0 PID= $$"
$ echo $$
8232
$ ./id2
./id2 PID= 8362
$ echo $$
8232

The first echo displays the PID number of the interactive shell. Then id2 displays its name ($0) and the PID number of the subshell it is running in. The last echo shows that the PID number of the interactive shell has not changed.

$!: PID Number of Most Recent Background Process

The shell expands $! to the value of the PID number of the most recent process that ran in the background. The following example executes sleep as a background task and uses echo to display the value of $!:

$ sleep 60 &
[1] 8376
$ echo $!
8376

$?: Exit Status

When a process stops executing for any reason, it returns an exit status to its parent process. The exit status is also referred to as a condition code or a return code. The shell expands the $? parameter to the exit status of the most recently executed command.

By convention, a nonzero exit status is interpreted as false and means the command failed; a zero is interpreted as true and indicates the command executed successfully. In the following example, the first ls command succeeds and the second fails; the exit status displayed by echo reflects these outcomes:

$ ls es
es
$ echo $?
0
$ ls xxx
ls: xxx: No such file or directory
$ echo $?
1

You can specify the exit status a shell script returns by using the exit builtin, followed by a number, to terminate the script. If you do not use exit with a number to terminate a script, the exit status of the script is that of the last command the script ran.

$ cat es
echo This program returns an exit status of 7.
exit 7
$ es
This program returns an exit status of 7.
$ echo $?
7
$ echo $?
0

The es shell script displays a message and terminates execution with an exit command that returns an exit status of 7, the user-defined exit status in this script. The first echo then displays the exit status of es. The second echo displays the exit status of the first echo: This value is 0, indicating the first echo executed successfully.

$–: Flags of Options That Are Set

The shell expands the $– parameter to a string of one-character bash option flags. These flags are set by the set or shopt builtins, when bash is invoked, or by bash itself (e.g., –i). For more information refer to “Controlling bash: Features and Options” on page 398. The following command displays typical bash option flags for an interactive shell:

$ echo $-
himBH

Table 9-13 on page 401 lists each of these flags (except i) as options to set in the Alternative syntax column. When you start an interactive shell, bash sets the i (interactive) option flag. You can use this flag to determine if a shell is being run interactively. In the following example,display_flags displays the bash option flags. When run as a script in a subshell, it shows the i option flag is not set; when run using source (page 332), which runs a script in the current shell, it shows the i option flag is set.

$ cat display_flags
echo $-

$ ./display_flags
hB

$ source ./display_flags
himBH

$_: Last Argument of Previously Executed Command

When bash starts, as when you run a shell script, it expands the $_ parameter to the pathname of the file it is running. After running a command, it expands this parameter to the last argument of the previously executed command.

$ cat last_arg
echo $_
echo here I am
echo $_

$ ./last_arg
./last_arg
here I am
am

In the next example, the shell never executes the echo command; it expands $_ to the last argument of the ls command (which it executed, albeit unsuccessfully).

$ ls xx && echo hi
ls: cannot access xx: No such file or directory
$ echo $_
xx

Variables

Variables, introduced on page 352, are shell parameters denoted by a name. Variables can have zero or more attributes (page 356; e.g., export, readonly). You, or a shell program, can create and delete variables, and can assign values and attributes to variables. This section adds to the previous coverage with a discussion of the shell variables, environment variables, inheritance, expanding null and unset variables, array variables, and variables in functions.

Shell Variables

By default, when you create a variable it is available only in the shell you created it in; it is not available in subshells. This type of variable is called a shell variable. In the following example, the first command displays the PID number of the interactive shell the user is working in (2802) and the second command initializes the variable x to 5. Then a bash command spawns a new shell (PID 29572). This new shell is a child of the shell the user was working in (a subprocess; page 373). The ps –l command shows the PID and PPID (parent PID) numbers of each shell: PID 29572 is a child of PID 2802. The final echo command shows the variable x is not set in the spawned (child) shell: It is a shell variable and is local to the shell it was created in.

$ echo $$
2802

$ x=5
$ echo $x
5

$ bash
$ echo $$
29572

$ ps -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 S 1000 2802 2786 0 80 0 - 5374 wait pts/2 00:00:00 bash
0 S 1000 29572 2802 0 80 0 - 5373 wait pts/2 00:00:00 bash
0 R 1000 29648 29572 0 80 0 - 1707 - pts/2 00:00:00 ps
$ echo $x

$

Environment, Environment Variables, and Inheritance

This section explains the concepts of the command execution environment and inheritance.

Environment

When the Linux kernel invokes a program, the kernel passes to the program a list comprising an array of strings. This list, called the command execution environment or simply the environment, holds a series of name-value pairs in the form name=value.

Environment Variables

When bash is invoked, it scans its environment and creates parameters for each name-value pair, assigning the corresponding value to each name. Each of these parameters is an environment variable; these variables are in the shell’s environment. Environment variables are sometimes referred to as global variables or exported variables.

Inheritance

A child process (a subprocess; see page 373 for more information about the process structure) inherits its environment from its parent. An inherited variable is an environment variable for the child, so its children also inherit the variable: All children and grandchildren, to any level, inherit environment variables from their ancestor. A process can create, remove, and change the value of environment variables, so a child process might not inherit the same environment its parent inherited.

Because of process locality (next), a parent cannot see changes a child makes to an environment variable and a child cannot see changes a parent makes to an environment variable once the child has been spawned (created). Nor can unrelated processes see changes to variables that have the same name in each process, such as commonly inherited environment variables (e.g., PATH).

Process Locality: Shell Variables

Variables are local, which means they are specific to a process: Local means local to a process. For example, when you log in on a terminal or open a terminal emulator, you start a process that runs a shell. Assume in that shell the LANG environment variable (page 368) is set toen_US.UTF-8.

If you then log in on a different terminal or open a second terminal emulator, you start another process that runs a different shell. Assume in that shell the LANG environment variable is also set to en_US.UTF-8. When you change the value of LANG on the second terminal to de_DE.UTF-8, the value of LANG on the first terminal does not change. It does not change because variables (both names and values) are local to a process and each terminal is running a separate process (even though both processes are running shells).

export: Puts Variables in the Environment

When you run an export command (a synonym for declare –x; page 357) with variable names as arguments, the shell places the names (and values, if present) of those variables in the environment. Without arguments, export lists environment (exported) variables.

The following extest1 shell script assigns the value of american to the variable named cheese and then displays its name (the shell expands $0 to the name of the calling program) and the value of cheese. The extest1 script then calls subtest, which attempts to display the same information, declares a cheese variable by initializing it, displays the value of the variable, and returns control to the parent process, which is executing extest1. Finally, extest1 again displays the value of the original cheese variable.

$ cat extest1
cheese=american
echo "$0 1: $cheese"
./subtest
echo "$0 2: $cheese"

$ cat subtest
echo "$0 1: $cheese"
cheese=swiss
echo "$0 2: $cheese"

$ ./extest1
./extest1 1: american
./subtest 1:
./subtest 2: swiss
./extest1 2: american

The subtest script never receives the value of cheese from extest1 (and extest1 never loses the value): cheese is a shell variable, not an environment variable (it is not in the environment of the parent process and therefore is not available in the child process). When a process attempts to display the value of a variable that has not been declared and is not in the environment, as is the case with subtest, the process displays nothing; the value of an undeclared variable is that of the null string. The final echo shows the value of cheese in extest1 has not changed: In bash—unlike in the real world—a child can never affect its parent’s attributes.

The extest2 script is the same as extest1 except it uses export to put cheese in the environment of the current process. The result is that cheese appears in the environment of the child process running the subtest script.

$ cat extest2
export cheese=american
echo "$0 1: $cheese"
./subtest
echo "$0 2: $cheese"

$ ./extest2
./extest2 1: american
./subtest 1: american
./subtest 2: swiss
./extest2 2: american

Here the child process inherits the value of cheese as american and, after displaying this value, changes its copy to swiss. When control is returned to the parent, the parent’s copy of cheese retains its original value: american.

Alternately, as the next program shows, you can put a variable in the environment of a child shell without declaring it in the parent shell. See page 148 for more information on this command-line syntax.

$ cheese=cheddar ./subtest
./subtest 1: cheddar
./subtest 2: swiss
$ echo $cheese

$

You can export a variable without/before assigning a value to it. Also, you do not need to export an already-exported variable after you change its value. For example, you do not usually need to export PATH when you assign a value to it in ~/.bash_profile because it is typically exported in a global startup file.

You can place several export declarations (initializations) on a single line:

$ export cheese=swiss coffee=colombian avocados=us

Unexport

An export –n or declare +x command removes the export attribute from the named environment variable (unexports the variable), demoting it to become a shell variable while preserving its value.

Export a function

An export –f command places the named function (page 396) in the environment so it is available to child processes.

printenv: Displays Environment Variable Names and Values

The printenv utility displays environment variable names and values. When called without an argument, it displays all environment variables. When called with the name of an environment variable, it displays the value of that variable. When called with the name of a variable that is not in the environment or has not been declared, it displays nothing. You can also use export (page 1032) and env (next page) to display a list of environment variables.

$ x=5 # not in the environment
$ export y=10 # in the environment
$ printenv x
$ printenv y
10
$ printenv
...
SHELL=/bin/bash
TERM=xterm
USER=sam
PWD=/home/sam
y=10
...

env: Runs a Program in a Modified Environment

The env utility runs a program as a child of the current shell, allowing you to modify the environment the current shell exports to the newly created process. See page 148 for an easier way to place a variable in the environment of a child process. The env utility has the following syntax:

env [options] [-] [name=value] ... [command-line]

where options is one of the following options:

––ignore-environment

–i or –

Causes command-line to run in a clean environment; no environment variables are available to the newly created process.

––unset=name –u name

Unsets the environment variable named name so it is not available to the newly created process.

Just as on a bash command line (page 148), zero or more name=value pairs may be used to set or modify environment variables in the newly created process, except you cannot specify a name without a value. The env utility evaluates the name=value pairs from left to right, so if nameappears more than once in this list, the rightmost value takes precedence.

The command-line is the command (including any options and arguments) that env executes. The env utility takes its first argument that does not contain an equal sign as the beginning of the command line and, if you specify a command that does not include a slash (i.e., if you specify a simple filename), uses the value of PATH (page 359) to locate the command. It does not work with builtin commands.

In the following example, env runs display_xx, a script that displays the value of the xx variable. On the command line, env initializes the variable xx in the environment of the script it calls and echo in the script displays the value of xx.

$ cat display_xx
echo "Running $0"
echo $xx

$ env xx=remember ./display_xx
Running ./display_xx
remember

If you want to declare only environment variables for a program, it is simpler to use the following bash syntax (page 148):

$ xx=remember ./display_xx
Running ./display_xx
remember

When called without a command-line, env displays a list of environment variables (it behaves similarly to printenv [page 1034]):

$ env
...
SHELL=/bin/bash
TERM=xterm
USER=sam
PWD=/home/sam
y=10
...

set: Works with Shell Features, Positional Parameters, and Variables

The set builtin can perform the following tasks:

• Set or unset shell features (also called attributes; page 400).

• Assign values to positional parameters (page 1024).

• Display variables that are available to the current shell. These variables comprise shell variables (variables not in the environment) and environment variables. The set builtin displays variables in a format you can use in a shell script or as input to set to declare and initialize variables. Output is sorted based on the current locale (page 368). You cannot reset readonly variables.

$ set

...
BASH=/bin/bash
COLUMNS=70
PWD=/home/sam
SHELL=/bin/bash
x=5
y=10
...

Expanding Null and Unset Variables

The expression ${name} (or just $name if it is not ambiguous) expands to the value of the name variable. If name is null or not set, bash expands ${name} to a null string. The Bourne Again Shell provides the following alternatives to accepting the null string as the value of the variable:

• Use a default value for the variable.

• Use a default value and assign that value to the variable.

• Display an error.

You can choose one of these alternatives by using a modifier with the variable name. In addition, you can use set –o nounset (page 402) to cause bash to display an error message and exit from a script whenever the script references an unset variable.

:– Uses a Default Value

The :– modifier uses a default value in place of a null or unset variable while allowing a nonnull variable to represent itself:

${name:–default}

The shell interprets :– as “If name is null or unset, expand default and use the expanded value in place of name; else use name.”

The following command lists the contents of the directory named by the LIT variable. If LIT is null or unset, it lists the contents of /home/max/literature:

$ ls ${LIT:-/home/max/literature}

The shell expands variables in default:

$ ls ${LIT:-$HOME/literature}

:= Assigns a Default Value

The :– modifier does not change the value of a variable. However, you can change the value of a null or unset variable to the expanded value of default by using the := modifier:

${name:=default}

The shell expands the expression ${name:=default} in the same manner as it expands ${name:–default}, but also sets the value of name to the expanded value of default.

If a script contains a line such as the following and LIT is unset or null at the time this line is executed, the shell assigns LIT the value /home/max/literature:

$ ls ${LIT:=/home/max/literature}

: (null) builtin

Some shell scripts include lines that start with the : (null) builtin followed on the same line by the := expansion modifier. This syntax sets variables that are null or unset. The : builtin evaluates each token in the remainder of the command line but does not execute any commands.

Use the following syntax to set a default for a null or unset variable in a shell script (a SPACE follows the first colon). Without the leading colon (:), the shell would evaluate and attempt to execute the “command” that results from the evaluation.

: ${name:=default}

When a script needs a directory for temporary files and uses the value of TEMPDIR for the name of this directory, the following line assigns to TEMPDIR the value /tmp if TEMPDIR is null:

: ${TEMPDIR:=/tmp}

:? Sends an Error Message to Standard Error

Sometimes a script needs the value of a variable, but you cannot supply a reasonable default at the time you write the script. In this case you want the script to exit if the variable is not set. If the variable is null or unset, the :? modifier causes the script to send an error message to standard error and terminate with an exit status of 1. Interactive shells do not exit when you use :?.

${name:?message}

If you omit message, the shell displays parameter null or not set. In the following command, TESTDIR is not set, so the shell sends to standard error the expanded value of the string following :?. In this case the string includes command substitution for date with the %T syntax, followed by the string error, variable not set.

cd ${TESTDIR:?$(date +%T) error, variable not set.}
bash: TESTDIR: 16:16:14 error, variable not set.

Array Variables

The Bourne Again Shell supports one-dimensional array variables. The subscripts are integers with zero-based indexing (i.e., the first element of the array has the subscript 0). The following syntax declares and assigns values to an array:

name=(element1 element2 ...)

The following example assigns four values to the array NAMES:

$ NAMES=(max helen sam zach)

You reference a single element of an array as follows; the braces are not optional.

$ echo ${NAMES[2]}
sam

The subscripts [*] and [@] both extract the entire array but work differently when used within double quotation marks. An @ produces an array that is a duplicate of the original array; an * produces a single element of an array (or a plain variable) that holds all the elements of the array separated by the first character in IFS (normally a SPACE; page 363). In the following example, the array A is filled with the elements of the NAMES variable using an *, and B is filled using an @. The declare builtin (page 357) with the –a option displays the values of the arrays (and reminds you that bash uses zero-based indexing for arrays):

$ A=("${NAMES[*]}")
$ B=("${NAMES[@]}")

$ declare -a
declare -a A='([0]="max helen sam zach")'
declare -a B='([0]="max" [1]="helen" [2]="sam" [3]="zach")'
...
declare -a NAMES='([0]="max" [1]="helen" [2]="sam" [3]="zach")'

The output of declare shows that NAMES and B have multiple elements. In contrast, A, which was assigned its value with an * within double quotation marks, has only one element: A has all its elements enclosed between double quotation marks.

In the next example, echo attempts to display element 1 of array A. Nothing is displayed because A has only one element and that element has an index of 0. Element 0 of array A holds all four names. Element 1 of B holds the second item in the array and element 0 holds the first item.

$ echo ${A[1]}

$ echo ${A[0]}
max helen sam zach
$ echo ${B[1]}
helen
$ echo ${B[0]}
max

The ${#name[*]} operator returns the number of elements in an array:

$ echo ${#NAMES[*]}
4

The same operator, when given the index of an element of an array in place of *, returns the length of the element:

$ echo ${#NAMES[1]}
5

You can use subscripts on the left side of an assignment statement to replace selected elements of an array:

$ NAMES[1]=max
$ echo ${NAMES[*]}
max max sam zach

Variables in Functions

Because functions run in the same environment as the shell that calls them, variables are implicitly shared by a shell and a function it calls.

$ nam () {
> echo $myname
> myname=zach
> }

$ myname=sam
$ nam
sam
$ echo $myname
zach

In the preceding example, the myname variable is set to sam in the interactive shell. The nam function then displays the value of myname (sam) and sets myname to zach. The final echo shows that, in the interactive shell, the value of myname has been changed to zach.

Function local variables

Local variables are helpful in a function written for general use. Because the function is called by many scripts that might be written by different programmers, you need to make sure the names of the variables used within the function do not conflict with (i.e., duplicate) the names of the variables in the programs that call the function. Local variables eliminate this problem. When used within a function, the local builtin declares a variable to be local to the function it is defined in.

The next example shows the use of a local variable in a function. It features two variables named count. The first is declared and initialized to 10 in the interactive shell. Its value never changes, as echo verifies after count_down is run. The other count is declared, using local, to be local to the count_down function. Its value, which is unknown outside the function, ranges from 4 to 1, as the echo command within the function confirms.

The following example shows the function being entered from the keyboard; it is not a shell script. See the tip “A function is not a shell script” on page 1017.

$ count_down () {
> local count
> count=$1
> while [ $count -gt 0 ]
> do
> echo "$count..."
> ((count=count-1))
> sleep 1
> done
> echo "Blast Off."
> }

$ count=10
$ count_down 4
4...
3...
2...
1...
Blast Off.
$ echo $count
10

The count=count–1 assignment is enclosed between double parentheses, which cause the shell to perform an arithmetic evaluation (page 1056). Within the double parentheses you can reference shell variables without the leading dollar sign ($). See page 397 for another example of function local variables.

Builtin Commands

Builtin commands, which were introduced in Chapter 5, do not fork a new process when you execute them. This section discusses the type, read, exec, trap, kill, and getopts builtins. Table 27-6 on page 1055 lists many bash builtin commands.

type: Displays Information About a Command

The type builtin provides information about a command:

$ type cat echo who if lt
cat is hashed (/bin/cat)
echo is a shell builtin
who is /usr/bin/who
if is a shell keyword
lt is aliased to 'ls -ltrh | tail'

The preceding output shows the files that would be executed if you gave cat or who as a command. Because cat has already been called from the current shell, it is in the hash table (page 376) and type reports that cat is hashed. The output also shows that a call to echo runs the echo builtin,if is a keyword, and lt is an alias.

read: Accepts User Input

A common use for user-created variables is storing information that a user enters in response to a prompt. Using read, scripts can accept input from the user and store that input in variables. The read builtin reads one line from standard input and assigns the words on the line to one or more variables:

$ cat read1
echo -n "Go ahead: "
read firstline
echo "You entered: $firstline"

$ ./read1
Go ahead: This is a line.
You entered: This is a line.

The first line of the read1 script uses echo to prompt for a line of text. The –n option suppresses the following NEWLINE, allowing you to enter a line of text on the same line as the prompt. The second line reads the text into the variable firstline. The third line verifies the action of read by displaying the value of firstline.

The –p (prompt) option causes read to send to standard error the argument that follows it; read does not terminate this prompt with a NEWLINE. This feature allows you to both prompt for and read the input from the user on one line:

$ cat read1a
read -p "Go ahead: " firstline
echo "You entered: $firstline"

$ ./read1a
Go ahead: My line.
You entered: My line.

The variable in the preceding examples is quoted (along with the text string) because you, as the script writer, cannot anticipate which characters the user might enter in response to the prompt. Consider what would happen if the variable were not quoted and the user entered * in response to the prompt:

$ cat read1_no_quote
read -p "Go ahead: " firstline
echo You entered: $firstline

$ ./read1_no_quote
Go ahead: *
You entered: read1 read1_no_quote script.1
$ ls
read1 read1_no_quote script.1

The ls command lists the same words as the script, demonstrating that the shell expands the asterisk into a list of files in the working directory. When the variable $firstline is surrounded by double quotation marks, the shell does not expand the asterisk. Thus the read1 script behaves correctly:

$ ./read1
Go ahead:*
You entered:*

REPLY

When you do not specify a variable to receive read’s input, bash puts the input into the variable named REPLY. The following read1b script performs the same task as read1:

$ cat read1b
read -p "Go ahead: "
echo "You entered: $REPLY"

The read2 script prompts for a command line, reads the user’s response, and assigns it to the variable cmd. The script then attempts to execute the command line that results from the expansion of the cmd variable:

$ cat read2
read -p "Enter a command: " cmd
$cmd
echo "Thanks"

In the following example, read2 reads a command line that calls the echo builtin. The shell executes the command and then displays Thanks. Next read2 reads a command line that executes the who utility:

$ ./read2
Enter a command: echo Please display this message.
Please display this message.
Thanks
$ ./read2
Enter a command: who
max pts/4 2013-06-17 07:50 (:0.0)
sam pts/12 2013-06-17 11:54 (guava)
Thanks

If cmd does not expand into a valid command line, the shell issues an error message:

$ ./read2
Enter a command: xxx
./read2: line 2: xxx: command not found
Thanks

The read3 script reads values into three variables. The read builtin assigns one word (a sequence of nonblank characters) to each variable:

$ cat read3
read -p "Enter something: " word1 word2 word3
echo "Word 1 is: $word1"
echo "Word 2 is: $word2"
echo "Word 3 is: $word3"
$ ./read3
Enter something: this is something
Word 1 is: this
Word 2 is: is
Word 3 is: something

When you enter more words than read has variables, read assigns one word to each variable, assigning all leftover words to the last variable. Both read1 and read2 assigned the first word and all leftover words to the one variable the scripts each had to work with. In the following example,read assigns five words to three variables: It assigns the first word to the first variable, the second word to the second variable, and the third through fifth words to the third variable.

$ ./read3
Enter something: this is something else, really.
Word 1 is: this
Word 2 is: is
Word 3 is: something else, really.

Table 27-4 lists some of the options supported by the read builtin.

Table 27-4 read options

The read builtin returns an exit status of 0 if it successfully reads any data. It has a nonzero exit status when it reaches the EOF (end of file).

The following example runs a while loop from the command line. It takes its input from the names file and terminates after reading the last line from names.

$ cat names
Alice Jones
Robert Smith
Alice Paulson
John Q. Public
$ while read first rest
> do
> echo $rest, $first
> done < names
Jones, Alice
Smith, Robert
Paulson, Alice
Q. Public, John
$

The placement of the redirection symbol (<) for the while structure is critical. It is important that you place the redirection symbol at the done statement and not at the call to read.