Sh

Table of Contents

• Bourne Shell, and filename expansion
• Shell Concepts
• Verifying which shell you are running
• Shell basics
• Meta-characters and Filename expansion
• Finding the executable
• Quoting with the Bourne Shell
• Nested quotations
• Strong versus weak quoting
• Quoting over several lines
• Mixing quotation marks
• Quotes within quotes - take two
• Placing variables within strings
• Variables
• A subtle point
• The set command
• Environment Variables
• Special Environment Variables
• PATH - Sets searchpath
• HOME - Your home directory
• CDPATH - cd searchpath
• IFS - Internal Field Seperator
• PS1 - Normal Prompt
• PS2 - Secondary Prompt
• MAIL - Incoming mail
• MAILCHECK - How often to check for mail
• SHACCT - Accounting file
• MAILPATH - searchpath for mail folders
• Bourne Shell Variables - Alternate Formats
• Using quoting and shell variables
• Using curly braces with variables
• ${variable?value} - Complain if undefined
• ${variable-default} - Use default if undefined
• ${variable+value} - Change if defined
• ${variable=value} - Redefine if undefined
• Undefining Variables
• ${x:-y}, ${x:=y}, ${x:?y}, ${x:+y} forms
• Order of evaluation
• Special Variables in the Bourne Shell
• Positional Parameters $1, $2, ..., $9
• $0 - Scriptname
• $* - All positional parameters
• $@ - All positional parameters with spaces
• $# - Number of parameters
• $$ - Current process ID
• $! - ID of Background job
• $? - error status
• $- Set variables
• Options and debugging
• Special options
• X - Bourne Shell echo flag
• V - Bourne Shell verbose flag
• Combining flags
• U - unset variables
• N - Bourne Shell non-execute flag
• E - Bourne Shell exit flag
• T - Bourne Shell test one command flag
• A - Bourne Shell mark for export flag
• K - Bourne Shell keyword flag
• H - Bourne Shell hash functions flag
• The $- variable
• - - Bourne Shell hyphen option
• Other options
• C - Bourne Shell command option
• S - Bourne Shell shell-session option
• I - Bourne Shell shell-interactive option
• R - Bourne Shell restricted shell option
• P - Bourne Shell privileged shell option
• unset
• Bourne Shell: Status, Pipes and branches
• Unnecessary process execution
• $@ versus ${1+$@}
• Status and Wasted Processes
• Simple Flow Control
• Changing Precedence
• Putting it all together
• Bourne Shell Flow Control Commands: If, While and Until
• Commands that must be first on the line
• While - loop while true
• Until - loop until true
• Bourne Shell Flow Control Commands
• For - Repeating while changing a variable
• Case - Checking multiple cases
• Break and continue
• Expr - Bourne Shell Expression Evaluator
• Arithmetic Operators
• Relational Operators
• Boolean Operators
• The string operator
• Precedence of the Operators
• Berkeley Extensions
• Bourne Shell -- Functions and argument checking
• Passing values by name
• Exiting from a function
• Checking the number of arguments
• UNIX conventions for command line arguments
• Checking for optional arguments

Copyright 2001 Bruce Barnett and General Electric Company

All rights reserved

You are allowed to print copies of this tutorial for your personal use, and link to this page, but you are not allowed to make electronic copies, or redistribute this tutorial in any form without permission.

How to build your own complex commands from the simple commands in the UNIX toolbox. This tutorial discusses of Bourne shell programming, describing the basic control structures used in this book. We've touched on shell programming earlier, and we'll see it often again. You're not getting the most out of UNIX if you can't write shell programs!

Bourne Shell, and filename expansion

This sections covers the Bourne shell. The manual pages are only 10 pages long, so it shouldn't be difficult to learn, right? Well, apparently I'm wrong, because most of the people I know learned one shell to customize their environment, and stayed with the C shell ever since. I understand the situation. It's hard enough to learn one shell language, and after struggling with one shell for a while, they are hesitant to learn another shell. After a few scripts, the new user decides the C shell is "good enough for now" and it ends right there. They never take the next step, and learn the Bourne shell. Well, perhaps this chapter will help.

The Bourne shell is considered the primary shell in scripts. All UNIX systems have it, first of all. Second, the shell is small and fast. It doesn't have the interactive features of the C shell, but so what? Interactive features aren't much use in scripts. There are also some features the Bourne shell has that the C shell doesn't have. All in all, many consider the Bourne shell to be the best shell for writing portable UNIX scripts.

Shell Concepts

There are four important concepts in a UNIX shell:

·

The user interacts with the system using a shell.

·

A sequence of operations can be scripted, or automatic, by placing the operations in a script file.

·

A shell is a full featured programming language, with variables, conditional statements, and the ability to execute other programs. It can be, and is, used to prototype new programs.

·

A shell allows you to easily create a new program that is not a "second-class citizen," but instead is a program with all of the privileges of any other UNIX program.

The last two points are important. DOS does not have a shell that has as many features as the Bourne shell. Also, it is impossible to write a DOS script that emulates or replaces existing commands.

Let me give an example. Certain DOS programs understand the meta-character "*." That is, the "RENAME" command can be told

RENAME *.OLD *.NEW

Files "A.OLD" and "B.OLD" will be renamed "A.NEW" and "B.NEW." The DOS commands "COPY" and "MOVE" also understand the character "*." The "TYPE" and "MORE" commands, however, do not. If you wanted to create a new command, it too, would not understand that an asterisk is used to match filenames. You see, each DOS program is given the burden of understanding filename expansion. Consequently, many programs do not.

UNIX is a different story. The shell is given the burden of expanding filenames. The program that sees the filenames is unaware of the original pattern. This means all programs act consistently, as filename expansion can be used with any command. It also means a shell script can easily replace a C program, as far as the user is concerned. If you don't like the name of a UNIX utility, it is easy to create a new utility to replace the current program. If you wanted to create a program called "DIR" you could simply create a file containing

#!/bin/sh
ls $*

The other difference between the DOS batch file and the UNIX shell is the richness of the shell language. It is possible to do software development using the shell as the top level of the program. Not only is it possible, but it is encouraged. The UNIX philosophy of program development is to start with a shell script. Get the functionality you want. If the end results has all of the functionality, and is fast enough, then you are done. If it isn't fast enough, consider replacing part (or all) of the script with a program written in a different language (e.g. C, Perl). Just because a UNIX program is a shell script does not mean it isn't a "real" program.

Verifying which shell you are running

You can execute the following command to determine your default shell (The command you type is in boldface):

% echo $SHELL
/bin/csh

#!/bin/sh

chmod +x filename

Once you do this, you can test the script by typing

./filename

The second method is to create a new window (if you desire). Then type

sh

% /bin/sh
$

The Bourne shell will execute each line you type, until an end of file is found. To put it another way, when you type Control-D, the Bourne shell will terminate, and return you to the shell you were previously using. This is the same action the shell takes when a script file is executed, and the end of the script file is reached.

Shell basics

Meta-characters and Filename expansion

+-------------------------------------------------------------------------------+
|				    Table 1					|
|			 Examples of filename expansion				|
+-------------------------------------------------------------------------------+
|Pattern	Matches								|
|*		Every file in the current directory				|
|?		Files consisting of one character				|
|??		Files consisting of two characters				|
|??*		Files consisting of two or more characters			|
|[abcdefg]	Files consisting of a single letter from a to g.		|
|[gfedcba]	Same as above							|
|[a-g]		Same as above							|
|[a-cd-g]	Same as above							|
|[a-zA-Z0-9]	Files that consist of a single letter or number			|
|[!a-zA-Z0-9]	Files that consist of a single character not a letter or number |
|[a-zA-Z]*	Files that start with a letter					|
|?[a-zA-Z]*	Files whose second character matches a letter.			|
|*[0-9]		Files that end with a number					|
|?[0-9]		Two character filename that end with a number			|
|*.[0-9]	Files that end with a dot and a number				|
+-------------------------------------------------------------------------------+

Files whose name starts with a dot are not normally listed.

.??

or

.[a-zA-Z]*

As I said, this does not match all combinations, but works most of the time. Hackers (or crackers, if you prefer) break into computers and often use strange filenames, like ". " or ".. " to hide their traces. You may not have noticed, but there was a space in these filenames. Refering to files with spaces in the names require quoting, which I will cover later. Personally, all of my hidden files are matched by ".[a-z]*" and all of my hidden directories are matched by ".[A-Z]*." This works because I made up my own convention, and always follow it.

The slash is also special, as it is used to indicate a directory path. Filename expansion does not expand to match a slash, because a slash can never be part of the filename. Also, the same rules for filename expansion of hidden files applies if the pattern follows a slash. If you want to match hidden files in a subdirectory, you must specify the explicit pattern. Table 2 lists some examples.

+--------------------------------------------------------------+
|			    Table 2			       |
|	      Filename Expansion with directories	       |
|Pattern   Matches					       |
+--------------------------------------------------------------+
|*	   All non-invisible files			       |
1.cp 0							       |
|abc/*	   All non-invisible files in directory abc	       |
|abc/.*	   All invisible files in directory abc		       |
|*/*	   All non-invisible files in all subdirectories below |
|*/.*	   All invisible files in all subdirectories below     |
+--------------------------------------------------------------+

The Bourne shell differs from the C shell if the meta-characters do not match any file. If this happens, the pattern is passed to the program unchanged. (The C shell will either do this, or generate an error, depending on a variable).

If you are not sure how something will expand, use the echo command to check. It generates output more compact than ls, and it will not list contents of directories like ls will. You will also notice the output is sorted alphabetically. The shell not only expans filenames, but sorts them, for all applications.

Finding the executable

If you have been following the points I made, it should not surprise you that a valid UNIX command might be

*

So you see, filename expansion can be anywhere on a command line. You can execute programs with long names without typing the entire name. However, filename expansion only works if the file is in the directory you specify. If you wanted to execute the program "my_very_own_program" without typing the complete filename, you could type

my_* arguments

/usr/local/bin/my_* arguments

Understanding the relationship between the shell and the programs allows you to add features. Some people create a file called "-i" in a directory. If someone then types

rm *

One last point. Many DOS users complain that they can't execute

RENAME *.OLD *.NEW

I admit that this is a little awkward to do in UNIX. I'd like to say two things in defense. First, the above usage of filename expansion is an "unnatural act," as far as UNIX is concerned. There are many advantages to the shell handling the filename expansion, and perhaps one disadvantage. I believe the advantages outweight the disadvanges. Second, I don't believe it is a disadvantage anyway. Renaming files like that is wrong. The only reason to do so is because DOS does it that way. If you must rename them, append a string to the end, instead of changing the original filename. This is UNIX. You can have filenames 256 characters long, so this approach isn't a problem. Even better, move the files into another directory, letting them keep their original name. I would suggest you type

mkdir Old
mv *.old Old

Quoting with the Bourne Shell

Quoted characters do not have a special meaning

A surprising number of characters have special meanings. The lowly space, often forgotten in many books, is an extremely important meta-character. Consider the following:

rm -i file1 file2

Can a file have a space in the name? Absolutely. This is UNIX. There are few limitations in filenames. As far as the operating system is concerned, You can't have a filename contain a slash or a null. The shell is a different story, and one I don't plan to discuss.

Normally, a space delineates arguments. To include a space in a filename, you must quote it. Another verb used in the UNIX documentations is "escape;" this typically refers to a single character. You "quote" a string, but "escape" a meta-character. In both cases, all special characters are treated as regular characters.

Assume, for a moment, you had a file named "file1 file2," This is one file, with a space between the "1" and the "f." If this file is to be deleted, one way to quote the space is

rm 'file1 file2'

rm 'file1 file2'
rm file1' 'file2
rm f'ile1 file'2

In other words, when reading a shell script, you must remember the current "quoting state." The quote toggles the state. Therefore if you see a quotation mark in the middle of a line, it may be turning the toggle on or off. You must start from the beginning, and group the quotation marks in pairs.

There are two other forms or quoting. The second uses a backslash "," which only acts to "escape" the next character. The double quotation mark is similar to the single quotes used above, but weaker. I'll explain strong and weak quotation later on. Here is the earlier example, this time using the other forms of quoting:

rm "file1 file2"
rm file1 file2
rm file1" "file2

Nested quotations

echo '"'
echo """
echo "

echo ''
echo ""
echo

As you can see, single quotes and double quotes behave differently. A double quote is weaker, and does not quote a backslash. Single quotes are different again. You can escape them with a backslash, or quote them with double quotes:

echo '
echo "'"

The following does not work:

echo '''

It is identical to

echo '

Strong versus weak quoting

Weak quotation marks treat most characters as plain characters, but allow certain characters (or rather meta-characters) to have a special meaning. As the earlier example illustrates, the backslash within double quotation marks is a special meta-character. It indicates the next character is not, so it can be used before a backslash and before a double quotation mark, escaping the special meaning. There are two other meta-characters that are allowed inside double quotation marks: the dollar sign, and the back quote.

Dollar signs indicate a variable. One important variable is "HOME" which specifies your home, or starting directory. The following examples illustrates the difference:

$ echo '$HOME'
$HOME
$ echo '$HOME'
$HOME
$ echo "$HOME"
/home/barnett
$ echo "$HOME"
$HOME

The back quote does command substitution. The string between backquotes is executed, and the results replaces the backquoted string:

$ echo 'The current directory is `pwd`'
The current directory is `pwd`
$ echo 'The current directory is `pwd`'
The current directory is `pwd`
$ echo "The current directory is `pwd`"
The current directory is `/home/barnett`
$ echo "The current directory is `pwd`"
The current directory is `pwd`

Quoting over several lines

$ echo 'Don't do this'
> ls
> pwd
> '
Dont do this
ls
pwd
$

This is a minor inconvenience if you use the shell interactively, but a large benefit when writing shell scripts that contain multiple lines of quoted text. I used the C shell for my first scripts, but I soon realized how awkward the C shell was when I included a multi-line awk script insice the C shell script. The Bourne shell's handling of awk scripts was much easier:

#!/bin/sh
# Print a warning if any disk is more
# than 95% full.
/usr/ucb/df | tr -d '%' | awk '
# only look at lines where the first field contains a "/"
$1 ~ /// { if ($5 > 95) {
printf("Warning, disk %s is %4.2f%% fulln",$6,$5);
}
}'

Click here to get file: diskwarn.sh

Mixing quotation marks

echo "Don't forget!"
echo 'Warning! Missing keyword: "end"'

Quotes within quotes - take two

echo abcd
echo 'abcd'
echo ab'c'd
echo a"b"cd
echo 'a'"b"'c'"d"

The last example protects each of the four letters from special interpretation, and switches between strong and weak quotation marks for each letter. Letters do not need to be quoted, but I wanted a simple example. If I wanted to include a single quote in the middle of a string delineated by a single quote marks, I'd switch to the different form of quotes when that particular character is encountered. That is, I'd use the form

'string1'"string2"'string3'

where string2 is a single quote character. Here is the real example:

$ echo 'Strong quotes use '"'"' and weak quotes use "'
Strong quotes use ' and weak quotes use "

Placing variables within strings

echo "My home directory is $HOME, and my account is $USER"

You will find that this form is also useful:

echo 'My home directory is '$HOME', and my account is '$USER

Variables

variable=value

question='What is the filename? '

A=1 B=2 C=3 D=4

a=date

a= date

A subtle point

VAR=/usr/lib; export VAR

VAR=/usr/lib export VAR

Ready?

What does the following Bourne shell commands do?

a=one; echo $a
a=two echo $a
a=three echo $a >$a

a=two echo one

Ready for a curve ball? What does the last line do? It creates a file. The file contains the word "two." For $64,000 and a trip to Silicon Valley, what is the name of the file that is created? For those to thought the answer is "two," I'm terrible sorry, you didn't win the grand price. We do have a nice home version of this game, and a year's supply of toothpaste. The correct answer is "three." In other words

echo $a >$a

echo second >third

a=output >$a

The set command

$ set
DISPLAY=:0.0
HOME=/home/barnett
IFS=

LD_LIBRARY_PATH=/usr/openwin/lib:/usr/openwin/lib/server
LOGNAME=barnett
MAILCHECK=600
OPENWINHOME=/usr/openwin
PATH=/home/barnett/bin:/usr/ucb:/usr/bin
PS1=$
PS2=>
PWD=/home/barnett
SHELL=/bin/csh
TERM=vt100
USER=barnett
$

Environment Variables

As I mentioned before, the shell command "export" is used to update environment variables. The command

export a b c

marks the variables "a" "b" and "c," and all child processes will inherit the current value of the variable. With no arguments, it lists those variables so marked. The command "export" is necessary. Changing the value of an environment variable does not mean this change will be inherited. Example:

HOME=/
myprogram

When "myprogram" executes, the value of the "HOME" variable is not changed. However, in this example:

HOME=/
export HOME
myprogram

The command marks the variable. It does not copy the current value into a special location in memory. A variable can be marked for export before it is changed. That is,

export HOME
HOME=/
myprogram

Special Environment Variables

PATH - Sets searchpath

:/usr/bin:/usr/ucb

/usr/bin:/usr/ucb:

HOME - Your home directory

CDPATH - cd searchpath

CDPATH=$HOME:..
export CDPATH

IFS - Internal Field Seperator

PS1 - Normal Prompt

PS2 - Secondary Prompt

MAIL - Incoming mail

MAILCHECK - How often to check for mail

SHACCT - Accounting file

MAILPATH - searchpath for mail folders

In addition, several environment variables are specified by the login process. "TERM" defines the terminal type, and "USER" or "LOGNAME" defines your user ID. "SHELL" defines your default shell, and "TZ" specifies your time zone. Check the manual pages, and test your own environment to find out for sure. The external program "env" prints all current environment variables.

Bourne Shell Variables - Alternate Formats

mv $X $X.old

mv $X $X_new # WRONG!

mv Accounts

The mv command will take the offered arguments, and complain, as it always wants two or more variables. A similar problem will occur if you wish to add a letter or number to the value of a variable.

Using quoting and shell variables

$x"run"
$x'run'
$xrun
$x''run
$x""run
"$x"run

Using curly braces with variables

${x}run

This form for variables is very useful. You could standardize on it as a convention. But the real use comes from four variations of this basic form, briefly described below:

+-------------------------------------------------------------+
|Form		    Meaning				      |
+-------------------------------------------------------------+
|${variable?word}   Complain if undefined		      |
|${variable-word}   Use new value if undefined		      |
|${variable+word}   Opposite of the above		      |
|${variable=word}   Use new value if undefined, and redefine. |
+-------------------------------------------------------------+

${variable?value} - Complain if undefined

#!/bin/sh
cat ${HOME}/Welcome

But suppose the environment variable "HOME" is not set. Without the question mark, you might get a strange error. In this case, the program cat would complain, saying file "/Welcome" does not exist. Change the script to be

#!/bin/sh
cat ${HOME?}/Welcome

script: HOME: parameter null or not set

cat ${HOME?Dummy}/Welcome

Remember my discussion earlier on quoting? And how the shell will consider a whitespace to be the end of the word unless quoted? The solution should be obvious. Just quote the string, which makes the results one word:

cat ${HOME?"Please define HOME, and try again"}/Welcome

Simple, yet this makes a shell script more user-friendly.

${variable-default} - Use default if undefined

$ echo Y is $Y
Y is
$ echo Y is ${Y-default}
Y is default
$ Y=new
$ echo Y is ${Y-default}
Y is new
$

Think of the hyphen as a mnemonic for an optional value, as the hyphen is used to specify an option on a UNIX command line. Like the other example, the word can be more than a single word. Here are some examples:

${b-string}
${b-$variable}
${b-"a phrase with spaces"}
${b-"A complex phrase with variables like $HOME or `date`"}
${b-`command`}
${b-`wc -l </etc/passwd`}
${b-`ypcat passwd | wc -l`}

echo Maximum number of users are $MAXUSERS

echo Maximum number of users are ${MAXUSERS-`wc -l </etc/passwd`}

${variable+value} - Change if defined

echo ${A+"Current value of A is $A"}

This command does print a blank line if A does not have a value. To eliminate this, use either the Berkeley version of echo, or the System V version of echo:

/usr/bin/echo ${A+"A = $A"}"c"
/usr/ucb/echo -n ${A+"A = $A"}

${variable=value} - Redefine if undefined

$ echo Y is $Y
Y is
$ echo Y is ${Y=default}
Y is default
$ echo Y is $Y
Y is default
$

Undefining Variables

A=

you will discover that the above tests do not help. As far as they are concerned, the variable is defined. It just has the value of nothing, or null as the manual calls it. To undefine a variable, use the unset command:

unset A

or if you wish to unset several variables

unset A B C D E F G

${x:-y}, ${x:=y}, ${x:?y}, ${x:+y} forms

A=$B

A=

+----------------------------------------------------------------------+
|Form		     Meaning					       |
+----------------------------------------------------------------------+
|${variable:?word}   Complain if undefined or null		       |
|${variable:-word}   Use new value if undefined or null		       |
|${variable:+word}   Opposite of the above			       |
|${variable:=word}   Use new value if undefined or null, and redefine. |
+----------------------------------------------------------------------+

$ # a is undefined
$ b=""
$ c="Z"
$ echo a=${a-1}, b=${b-2}, c=${c-3}
a=1, b=, c=Z
$ echo a=${a:-1}, b=${b:-2}, c=${c:-3}
a=1, b=2, c=Z

Order of evaluation

echo ${x-`cd $HOME;pwd`}

echo `cd $HOME;pwd`

Special Variables in the Bourne Shell

Positional Parameters $1, $2, ..., $9

Then execute "chmod +x rename" and you have a new UNIX program. If you want to add some simple syntax checking to this script, using the techniques I discussed earlier, change the last line to read:

mv ${1?"missing: original filename"} ${2?"missing new filename"}

This isn't very user friendly. If you do not specify the first argument, the script will report:

rename: 1: missing: original filename

As you can see, the missing variable, in this case "1," is reported, which is a little confusing. A second way to handle this is to assign the positional variables to new names:

#!/bin/sh
# rename: - rename a file
# Usage: rename oldname newname
oldname=$1
newname=$2
mv ${oldname:?"missing"} ${newname:?"missing"}

Click here to get file: rename.sh

This will report the error as follows:

rename: oldname: missing

Notice that I had to add the colons before the question mark. Earlier I mentioned how the question mark tests for undefined parameters, while the colon before the question mark complains about empty parameters as well as undefined parameters. Otherwise, the mv command might have complained that it had insufficient arguments.

The Bourne shell can have any number of parameters. However, the positional parameters variables are limited to numbers 1 through 9. You might expect that $10 refers to the tenth argument, but it is the equivalent of the value of the first argument with a zero appended to the end of the value. The other variable format, ${10}, ought to work, but doesn't. The Korn shell does support the ${10} syntax, but the Bourne shell requires work-arounds. One of these is the shift command. When this command is executed, the first argument is moved off the list, and lost. Therefore one way to handle three arguments follows:

#!/bin/sh
arg1=$1;shift;
arg2=$1;shift;
arg3=$1;shift;
echo first three arguments are $arg1 $arg2 and $arg3

#!/bin/sh
arg1=$1
arg2=$2
arg3=$3;shift 3
echo first three arguments are $arg1 $arg2 and $arg3

$0 - Scriptname

echo $0: error

will report "rename: error" when the rename script executes it. This variable is not affected by the shift command.

$* - All positional parameters

If this script was called "moveto" then the command

moveto /tmp *

$@ - All positional parameters with spaces

#!/bin/sh
# Scriptname: EchoArgs
# It echoes arguments
#First - make sure we are using the Berkeley style echoes
PATH=/usr/ucb:$path;export PATH
E="echo -n"
# echo the name of the script
${E} $0:
# now echo each argument, but put a space
# before the argument, and place single quotes
# around each argument
${E} " '${1-"?"}'"
${E} " '${2-"?"}'"
${E} " '${3-"?"}'"
${E} " '${4-"?"}'"
${E} " '${5-"?"}'"
${E} " '${6-"?"}'"
${E} " '${7-"?"}'"
echo

Click here to get file: EchoArgs.sh

Second, here is a script that tests the difference:

#!/bin/sh
EchoArgs $*
EchoArgs $@
EchoArgs "$*"
EchoArgs "$@"

Click here to get file: TestEchoArgs.sh

Now, let's execute the script with arguments that contain spaces:

./TestEcho "a b c" 'd e' f g

./EchoArgs: 'a' 'b' 'c' 'd' 'e' 'f' 'g'
./EchoArgs: 'a' 'b' 'c' 'd' 'e' 'f' 'g'
./EchoArgs: 'a b c d e f g' '?' '?' '?' '?' '?' '?'
./EchoArgs: 'a b c' 'd e' 'f' 'g' '?' '?' '?'

$# - Number of parameters

newscript a b c d

newscript "a b c" 'd e' f g

shift $#

$$ - Current process ID

Another use of this variable is to allow one process to stop a second process. Suppose the first process executed

echo $$ >/tmp/job.pid

A second script can kill the first one, assuming it has permissions, using

kill -HUP `cat /tmp/job.pid`

I hope you don't mind a brief discourse into signals, but these concepts are closely related, so it is worth while to cover them together. Any professional-quality script should terminate gracefully. That is, if you kill the script, there should be no extra files left over, and all of the processes should quit at the same time. Most people just put all temporary files in the /tmp directory, and hope that eventually these files will be deleted. They will be, but sometimes the temporary files are big, and can fill up the /tmp disk. Also some people don't mind if it takes a while for a script to finish, but if it causes the system to slow down, or it is sending a lot of error messages to the terminal, then you should stop all child processes of your script when your script is interrupted. This is done with a trap command, which takes one string, and any number of signals as an argument. Therefore a script that kills a second script could be written using:

#!/bin/sh
# execute a script that creates /tmp/job.pid
newscript &
trap 'kill -HUP `cat /tmp/job.pid`' 0 HUP INT TERM
# continue on, waiting for the other to finish
<rest of the script deleted>

Signals are a very crude form of inter-process communication. You can only send signals to processes running under your user name. HUP corresponds to a hang-up, INT is an interrupt, like a control-C, and TERM is the terminate command. You can use the numbers associated with these signals if you wish, which are 1, 2, and 15. Signal number zero is special. It indicates the script is finished. Therefore setting a trap at signal zero is a way to make sure some commands are done at the end of the script. Signal 1, or the HUP signal, is generally considered to be the mildest signal. Many programs use this to indicate the program should restart itself. Other signals typically mean stop soon (15), while the strongest signal (9) cannot be trapped because it means the process should stop immediately. Therefore if you kill a shell script with signal 9, it cannot clean up any temporary files, even if it wanted to.

$! - ID of Background job

#!/bin/sh
newscript &
trap "kill -TERM $!" 0 1 2 15
# do something else
wait $!

I used the numbers instead of the names of the signals. I used double quotes, so that the variable $! is evaluated properly. I also used the wait command, which causes the shell to sleep until that process is finished. This script will run two shell processes at the same time, yet if the user presses control-C, both processes die. Most of the time, shell programmers don't bother with this. However, if you are running several processes, and one never terminates (like a "tail -f)" then this sort of control is required. Another use is to make sure a script doesn't run for a long time. You can start a command in the background, and sleep a fixed about of time. If the background process doesn't finish by then, kill it:

#!/bin/sh
newscript &
sleep 10
kill -TERM $!

The wait command does not need an argument. If executed with no arguments, it waits for all processes to be finished. You can launch several jobs at once using

#!/bin/sh
job1 &
pid=$!
job2 &
pid="$pid $!"
job3 &
pid="$pid $!"
trap "kill -15 $pid" 0 1 2 15
wait

$? - error status

#!/bin/sh
# this is script1
exit 12

Then the following script

#!/bin/sh
script1
echo $?

would print 12.

$- Set variables

The variable "$-" corresponds to certain internal variables inside the shell. I'll discuss this next.

Options and debugging

The Bourne Shell set command is somewhat unusual. It has two purposes: setting certain shell options, and setting positional parameters. I mentioned positional parameters earlier. These are the arguments passed to a shell script. You can think of them as an array, of which you can only see the first nine values, by using the special variables $1 through $9. As I mentioned earlier, you can use the shift command to discard the first one, and move $2 to $1, etc. If you want to see all of your variables, the command

set

You can also explicitly set these variables, by using the set command. Therefore the Bourne shell has one array, but only one. You can place anything in this array, but you lose the old values. You can keep them, however, by a simple assignment:

old=$@
set a b c
# variable $1 is now equal to "a", $2=b, and $3=c
set $old
# variable $1 now has the original value, as does $2, etc.

This isn't perfect. If any argument has a space inside, this information isn't retained. That is, if the first argument is "a b," and the second is "c," then afterwards the first argument will be "a," the second "b," and the third "c." You may have to explicitly handle each one:

one=$1;two=$2;three=$3
set a b c
# argument $1 is "a", etc.
set "$one" "$two" "$three"
# argument $1, $2 and $3 are restored

If you wanted to clear all of the positional parameters, try this:

set x;shift

Special options

Excuse me, but I am going to fast. I'm teaching you how to run, before I explained walking. Let's discuss the first flag, and why it's useful.

X - Bourne Shell echo flag

#!/bin/sh
a=$1
echo a is $a

sh -x script abc

the script will print out

a=abc
+ echo a is abc
a is abc

The "x" variable shows you each line before it executes it. The second way to turn on this variable is to modify the first line of the script, i.e.:

#!/bin/sh -x

As you can see, the first way is convenient if you want to run the script once with the variable set, while the second is useful if you plan to repeat this several times in a row. A large and complex script, however, is difficult to debug when there are hundreds of lines to watch. The solution is to turn the variable on and off as needed, inside the script. The command

set -x

set +x

V - Bourne Shell verbose flag

#!/bin/sh
# comment
a=${1:-`whoami`};b=${2:-`hostname`}
echo user $a is using computer $b

+ whoami
a=barnett
+ hostname
b=grymoire
+ echo user barnett is using computer grymoire
user barnett is using computer grymoire

#!/bin/sh
# comment
a=${1:-`whoami`};b=${2:-`hostname`}
echo user $a is using computer $b
user barnett is using computer grymoire

As you can see, the comments are echoed with the verbose flag. Also, each line is echoed before the variables and the commands in backquotes are evaluated. Also note the "x" command echoes the assignment to variables a and b on two lines, while the verbose flag echoed one line. Perhaps the best way to understand the difference is the verbose flag echoes the line before the shell does anything with it, while the "x" flag causes the shell to echo each command. Think of it as a case of Before and After.

Combining flags

sh -x -v script

sh -xv script

set -x -v
set -xv
set +x +v
set +xv

#!/bin/sh -xv

#!/bin/sh -x -v

U - unset variables

N - Bourne Shell non-execute flag

E - Bourne Shell exit flag

#!/bin/sh
word=$1
grep $word my_file >/tmp/count
count=`wc -l </tmp/count`
echo I found $count words in my_file

set +e # ignore errors
grep $word my_file >/tmp/count
set -e

T - Bourne Shell test one command flag

sh -t script

A - Bourne Shell mark for export flag

a=newvalue
newscript

The script newscript will now know the value of variable "a."

in the environment with

export a

A second way to do this is to assign the variable right before executing the script:

a=newvalue newscript

This is an unusual form, and not often used. There is no semicolon on the line. If there was a semicolon between the assignment and myscript, the variable "a" would not be made an environment variable.

Another way to do this is to set the "a" option:

set -a

K - Bourne Shell keyword flag

a=1 myscript b=2 c d=3

Any assignment on the same line as a command is made an environment variable, but only if it's before the command. The "-k" options changes this All three assignments become environment variables, and the script only sees one argument.

H - Bourne Shell hash functions flag

The $- variable

#!/bin/sh
myscript arg1 arg2

If this is replaced by

#!/bin/sh
sh -$- myscript arg1 arg2

then if you typed "sh -x newscript," myscript would also see the "-x" option.

- - Bourne Shell hyphen option

set -xvua a b c

#!/bin/sh
# remember the old parameters
old=$@
set a b c
# $1, $2, $3 are changed.
# now - put them back
set $old

Looks simple. But what happens if you execute this script with the following arguments:

myscript -d abc

-d: bad option(s)

#!/bin/sh
# remember the old parameters
old=$@
set a b c
# $1, $2, $3 are changed.
# now - put them back, NOTE the change
set -- $old

Other options

C - Bourne Shell command option

sh -c "command"

sh -ac "a=1;env"

Since env prints all environment variables, you will see that variable "a" is indeed exported, and visible to the external program env.

S - Bourne Shell shell-session option

echo "echo a" | sh

will echo "a," while

echo "echo a" | sh myscript

will ignore standard input. The "s" option forces the shell to read standard input for commands. That is,

echo "echo a" | sh -s myscript

never executes the script myscript. Instead, it echoes "a" like the first example.

I - Bourne Shell shell-interactive option

R - Bourne Shell restricted shell option

P - Bourne Shell privileged shell option

unset

export JUNK
unset JUNK

Bourne Shell: Status, Pipes and branches

#!/bin/sh
/usr/local/`uname -s`/`uname -r`/`uname -m`/bin/`basename $0` "$@"

Your problem would be solved. Sort of. There are four problems with this script, or rather say, four ways to improve the script.

Unnecessary process execution

#!/bin/sh -a
OS=${OS=`uname -s`}
REV=${REV=`uname -r`}
ARCH=${ARCH=`uname -m`}
CMD=`basename $0`
/usr/local/$OS/$REV/$ARCH/bin/$CMD "$@"

The "-a" Bourne shell option says to mark all modified variables for auto-export. This script tests three environment variables, and if not defined, it sets these variables. You could, therefore, set these variables once when you log in. Thereafter, the uname program need not be executed.

$@ versus ${1+$@}

"$@"

""

The fix for these systems is to use the pattern:

${1+"$@"}

/usr/local/$OS/$REV/$ARCH/bin/$CMD ${1+"$@"}

Status and Wasted Processes

exec /usr/local/$OS/$REV/$ARCH/bin/$CMD ${1+"$@"}

Normally, the shell creates a copy of itself for each line, and then executes the command on the line with the new process. The exec command does the second step, without requiring the shell to copy itself. If the exec command succeeds, the shell never executes the next line.

The second problem with the script is the exit status. The version without the "exec" script does not execute the exit command. Therefore the exit status is zero. The one with the "exec" command never exits (unless the program isn't found). Instead, the program it executes exits, and the exit status is passed to the script that called the wrapper script. Why is this important? Well, the value of the status is the basis of flow control in the Bourne shell.

Simple Flow Control

command1 && command2
command1 || command2

As I have mentioned before, a program only has two ways to pass information to another process: a file/pipe, or the exit status. A program cannot use environment variables to pass information back to the process that created it. Most of the time a process does file I/O. The exit status is another quick and convenient method.

The status is an integer from 0 to 255. The shell can either examine the integer value of an exit status, or treat the value as a boolean. Zero is true, all other values are false. If you do not provide an exit status, the system returns with the status of the last command executed.

UNIX comes with two programs called true and false, which is simply the command "exit 0" and "exit 255." Well, the true program doesn't even have an exit command. Since no commands are executed, the exit status is zero. So, in essence, the true command does absolutely nothing, but takes nine lines, including the copyright notice, to do nothing. I should warn you, however, that if you ever create a shell script that does nothing, you risk the legal fury of the AT&T legal department for reverse engineering a program that took untold hours to develop.

That's the scoop. Using the status gives you flow control. The "&&" is often called the "and" operator. It executes the next command if the first command is true. The "||" operator is the "or" command, which executes if the command is false. To illustrate:

true && echo this line IS printed
false || echo this line IS printed
true || echo this line is NOT printed
false && echo this line is NOT printed

Substitute the words "and" or "or" in the above examples, and read them quietly to yourself to understand why. You can, if you wish, combine these operators one one line:

command && echo command succeeded || echo command failed

cmd1 ; cmd2 ; cmd3 ; cmd4
cmd1 & cmd2 & cmd3 & cmd4
cmd1 && cmd2 && cmd3 && cmd4
cmd1 || cmd2 || cmd3 || cmd4

a | b && c ; d || e | f ;

(a | (b && c)) ; ((d || e) | f) ;

Changing Precedence

(cmd1; cmd2) | cmd3
{ cmd1; cmd2; } | cmd3

a=OLD
(a=NEW) ; echo $a
{ a=NEW;} ; echo $a

Putting it all together

false && {
command1
command2
command3
}

Change the false to true, and the commands get executed. Braces and parenthesis can be nested:

A && {
B && {
echo "A and B both passed"
} || {
echo "A passed, B failed"
}
} || echo "A failed"

The parenthesis and curly brace are useful when you want to merge standard output of multiple commands. For instance, suppose you want to add a line containing "BEGIN" to the middle of a pipeline, before the "C" command:

A | B | C | D

A | B | echo "BEGIN" | C | D

A | B | echo "BEGIN" ; C | D

A | B | { echo "BEGIN" ; C;} | D
A | B | (echo "BEGIN" ; C) | D

echo BEGIN >/tmp/begin
A | B | cat /tmp/begin - | C | D

The parenthesis is useful when you want to change a state of the process without affecting the other processes. For example - changing the current directory. A common method of copying directory trees can be done with the tar command:

tar cvf . | ( cd newdirectory; tar xfBp - )

(stty 2400;cat file) >/dev/printer

One of the more powerful uses of these techniques is combining tests with pipes. You see, taking different branches does not automatically disconnect pipelines. The C shell doesn't do this well, but the Bourne shell does. Suppose you wanted a filter to read standard input, and if the input contains a special pattern, you want the filter to add a line before the stream of information. Otherwise, you wanted to add another line after the input stream. A simple way to do this is to use the shell's features:

#!/bin/sh
tee /tmp/file |
(grep MATCH /tmp/file >/dev/null && cat header - || cat - trailer )
/bin/rm /tmp/file

As you can see, a temporary file is created, and then the grep program searches the copy for a pattern. If found, the shell output's first the header, then the rest of the input stream. If not found, the stream is output, and then the trailer is appended. This works because the grep command reads standard reads standard input if no filename is provided as an argument. However, if a filename is provided, then standard input is ignored.

I should mention that most people test conditions using the if command instead of the "&&" and "||" operators. The structure might seem unusual at first, but the more you use it, the more uses you will find for it.

Bourne Shell Flow Control Commands: If, While and Until

What's a list? There are three ways commands can be grouped together:

A simple command
A pipeline
A list

1. A simple command is a collection of words separated by spaces.
2. A pipeline is a group of simple commands separated by a "|" character. Earlier versions of the shell used the "^" character instead of the pipe character. Older keyboards didn't have the pipe character. Newer versions of the shell use both. The exit status of the last command is the status the pipeline returns.
3. A list is a series of pipelines, separated by &, ;, &&, or ||, and terminated by a semicolon, ampersand, or new line character.

A command can either be a simple command, or a complex command. The complex commands can be one of those listed below:

if list then list fi
if list then list else list fi
if list then list elif list then list fi
if list then list elif list then list elif list then list fi
if list then list elif list then list else list fi
if list then list elif list then list elif list else list fi
while list do list done
until list do list done

The "if" commands can be nested. Therefore the above only lists some of the combinations. Also note than fi is if backwards.

Commands that must be first on the line

if
then
else
elif
fi
case
esac
for
while
until
do
done
{
}

if true
then
echo it was true
fi

(The indentation is done for convenience.) The same complex command may also be written:

if true; then echo it was true; fi

if list then list fi

The "if" command executes a list if the list after the "if" command is true. A list can have more than one command. The last one is used to make a decision:

if
false
false
true
then
echo this will print
fi

if testa; then
echo testa is true
elif testb; then
echo testb is true
else
if testc; then
echo testc is true
else
echo all tests fail
fi
fi

Some times you want to perform a test if the condition is false. You might try the following, but a syntax error would exist:

if condition
then
# ignore this
else
echo condition is false
fi

The "if," "then" and "else" statements must be followed by a list. A comment is not a list. There must be a command. In this case, the ":" command, which does nothing, can be used:

if condition; then :; else
echo condition is false
fi

While - loop while true

while mytest
do
echo mytest is still true
done;

while read a
do
echo $a
done

This can be used to ask for a list of arguments:

echo "Please type the arguments"
echo "Type Control-D (EOF) when done"
args="":
echo '?'
while read a
do
args="$args $a"
echo '?'
done
echo "The arguments are $args"

echo "Please type the arguments"
echo "Type Control-D (EOF) when done"
args="":
while
echo '?'
read a
do
args="$args $a"
done
echo "The arguments are $args"

cat file | while read a
do
file contains line $a
done

The "while" command can get its input from a subshell, and be placed inside a subshell. The following script

#!/bin/sh
(echo a b c;echo 1 2 3) | (while read a; do
echo $a $a
echo $a $a
done
) | tr a-z A-Z

generates the following output:

A B C A B C
A B C A B C
1 2 3 1 2 3
1 2 3 1 2 3

The following also works:

while read a
do
echo a=$a
done <file

There are a few subtle points about the "read" and "while" commands. The following is a syntax error:

while true
do
# comment
done

There must be a command in the list between the ""do" and "done" commands. The null command ":" will fix the syntax error:

while true
do
:
done

I expected

echo 1 2 3 | read a; echo a is $a

to work, but it doesn't. At least on the systems I tried, it doesn't work. However, the following does:

echo 1 2 3 | ( read a; echo a is $a )

<file (
read a ;echo a is $a
read a ;echo a is $a
read a ;echo a is $a
)

as does:

( read a ;echo a is $a
read a ;echo a is $a
read a ;echo a is $a
) <file

Exactly three lines of the file are read. I should emphasize the that C shell cannot do this easily. It does not have a built-in mechanism to read exact one line. Also the C shell command to read a single line only reads from the controlling terminal, and cannot be redirected to get input from a file, or a pipe, while the Bourne shell can.

What happens if the "read" command has more than one argument? The command breaks the input line into words, using whitespace as the characters between words. Each word is assigned to a different variables. If there are not enough words, the last variables are assigned an empty value. If there are too many, the last variable gets the leftovers. What gets printed if the following is executed?

echo 1 2 3 4 5 | (
read a b c
echo first $a
echo second $b
echo third $c
)

Together, these two commands provide a lot of flexibility, more so than what appears on the surface.

If you want to loop forever, you could do what most people do:

while true
do
echo never stop
done

while :
do
echo never stop
done

Until - loop until true

until testa
do
echo not yet
done

will echo "not yet" until "testa" becomes true (exits with a status of zero).

Next, the "for" and "case" commands.

Bourne Shell Flow Control Commands

for name do list done
for name in word ... do list done
case word in esac
case word in pattern ) list;; esac
case word in pattern | pattern ) list;; esac

For - Repeating while changing a variable

for i in 1 2 3 4 5 6 7 8 9 10
do
echo $i
done

numbers="1 2 3 4 5 6 7 8 9 10"
for i in $numbers
do
echo $i
done

for i in $numbers

to

for i in $numbers $numbers

for i in $numbers

for i in "$numbers"

for args in "a A" "b B" "c C"
do
set $args
echo lower case is $1, upper case is $2
done

for i in `ls file*`

#!/bin/sh
# read the /etc/password file
# use `cat /etc/passwd`, but spaces are treated like new lines
# therefore, change spaces into _

for i in `tr ' ' '_' </etc/passwd`
do
set `echo $i | tr ':' ' '`
echo user: $1, UID: $3, Home Directory: $6
done

for a in `cat`

for i in BEGIN $a "$b $c" `cat file` END
do
echo i is $i
done

Of course any variable besides "i" will work. You don't have to specify the list of values after the "in" command. If not specified, the positional arguments are used. To illustrate, if you had a script called "script1" and executed

script1 a b c

#!/bin/sh
echo $1 has `wc -l <$1` words
echo $2 has `wc -l <$2` words
echo $3 has `wc -l <$3` words

Another way to do the same is as follows:

#!/bin/sh
for file
do
echo $file has `wc -l <$file` words
done

Case - Checking multiple cases

case word in pattern | pattern ) list;; esac

Let's suppose you wanted to get a yes or no answer to a question. An example is:

echo answer yes or no
read word
case $word in
yes | YES )
echo you answered yes
;;
no | NO )
echo you answered no
;;
esac

The "case" statement works on patterns, like filename matching. The above example won't let you specify a single character. You must type the full word. If you type "Yes," it will not recognize it as a yes because the first letter is upper case, and the other letters are lower case. There is a fix. The patterns are filename patterns. Therefore you can modify the above script to be:

echo answer yes or no
read word
case $word in
[Yy]* )
echo you answered yes
;;
[Nn]* )
echo you answered no
;;
* )
echo you did not say yes or no;;
esac

You will notice the last test, containing an asterisk. This is the standard method of specifying a default condition for the "case" statement. The last pattern in this case will always match.

There can only be one word between "case" and "in." The following is a syntax error:

case a b c in

#!/bin/sh
arg="a b c"
case $arg in
[aAbBcC] ) echo this never matches;;
"a b c") echo this will match;;
esac

case $arg in
a ) echo yes; b ) echo no;;
esac

case $arg in
esac

Break and continue

while :
do
echo "Type yes or no"
read answer
case "$answer" in
[yYnN]*) break;;
ecas
done

The "continue" command causes the "for" or "while" command to go to the next loop immediately The following loop only prints the odd numbers:

for number in 1 2 3 4 5 6 7 8
do
case "$number" in
2|4|6|8) continue ;;
esac
echo $number
done

for number in 1 2 3 4 5 6
do
for letter in a b c d e f g
do
case $number in
3) break
esac
echo $number $letter
done
done

Expr - Bourne Shell Expression Evaluator

This section is on the expr command, used to perform expression evaluation.

The Bourne shell didn't originally have any mechanism to perform simple arithmetic. In older versions of UNIX, it used external programs, either awk or the must simpler program expr. In UNIX System V, and therefore in Solaris, expr was added to the Bourne shell, which increases the speed of any Bourne shell script that uses the built-in version. If the full path-name is used, the external version is executed, causing a slight speed penalty. There are four types of operations expr performs:

Arithmetic
Logical
Relational
String

+-------------------------------------------------+
     |Operator	    Type      Meaning		       |
     +-------------------------------------------------+
     |	  +	 Arithmetic   Addition		       |
     |	  -	 Arithmetic   Subtraction	       |
     |	  *	 Arithmetic   Multiplication	       |
     |	  /	 Arithmetic   Division		       |
     |	  %	 Arithmetic   Remainder		       |
     +-------------------------------------------------+
     |	  =	 Relational   Equal to		       |
     |	>	 Relational   Greater Than	       |
     |	>=	 Relational   Greater Than or Equal to |
     |	<	 Relational   Less Than		       |
     |	<=	 Relational   Less than or Equal to    |
     |	 !=	 Relational   Not Equal to	       |
     +-------------------------------------------------+
     |	  |	  Boolean     Or		       |
     |	&	  Boolean     And		       |
     +-------------------------------------------------+
     |	  :	   String     Match or substitute      |
     +-------------------------------------------------+

Not so obvious is how to use these operators. The general form is

expression operator expression

expr 2+2

expr 2 + 2

# 2 times 10
expr 2 * 10
# a complex expression
# true if both $a and $b are greater than zero
expr $a gt; 0 amp; $b gt; 0
# Another way to test this
expr $a '>' 0 '&' $b '>' 0

expr '2 + 2'

expr $a = '2 + 2'

expr no

Another potential problem is variables that contain operators. The following example, which looks like it might test if a variable is equal to an "=," generates an error:

A='='
# is $A an '='?
expr $A = '='
# WRONG - syntax error - same as 'expr = = ='

expr X$A = X=

Arithmetic Operators

# count from 1 to 10
A=1
while [ $A -le 10 ]
do
echo $A
A=`expr $A + 1`
done

Relational Operators

expr 1 = 1

expr $A = 1 > /dev/null && echo A = 1

A=1;
while expr $A '<=' 10 >/dev/null
do
A=`expr $A + 1`
echo $A
done

Boolean Operators

expr $a amp; $b

Not only does expr return a status, but it prints too! And it doesn't just print zero or one. It prints either zero, or the actual value of the expression, saving you time and money.

+----------------------------------------------+
      |Expression		Output	 Exit Status |
      +----------------------------------------------+
      |expr '' | ''		0	 1	     |
      |expr '' | 0		0	 1	     |
      |expr '' | 1		1	 0	     |
      |expr '' | A		A	 0	     |
      |expr 0 | ''		0	 1	     |
      |expr 0 | 1		1	 0	     |
      |expr 0 | A		A	 0	     |
      |expr 1 | anything	1	 0	     |
      |expr A | anything	A	 0	     |
      |expr '' & anything	0	 1	     |
      |expr 0 & anything	0	 1	     |
      |expr 1 & ''		0	 1	     |
      |expr 1 & 0		0	 1	     |
      |expr 1 & A		1	 0	     |
      |expr A & ''		0	 1	     |
      |expr A & 0		0	 1	     |
      |expr A & 1		A	 0	     |
      |expr A & B		A	 0	     |
      +----------------------------------------------+

The string operator

string : regular-expression

expr abc : abc

expr abc : abd

# prints the number characters in variable a
expr "$a" : '.*'
# prints the number of lower case letters
expr "$a" : '[a-z]*'
# prints the number of lower case letters
expr "$a" : '[0-9]*'

expr "$x" : '[^a-zA-Z]*[a-zA-Z]'

Parenthesis can be used in the regular expression, like the substitute command in sed. If a match is found, the substring within the parenthesis is returned. Therefore, if the variable "a" has the value "123abc," the two commands below output the same string, which is "abc."

# if $a = 123abc, then output 'abc'
expr "$a" : '[0-9]*([a-z]*)'
# same as above
echo $a | sed 's/^[0-9]*([a-z]*)/1/'

myscript -x123

x=`expr "$1" : '-x(.*)'`

The expr command can also be used to test if a variable is a number:

echo "Type in a number"
read ans
number=`expr "$ans" : "([0-9]*)"`
if [ "$number" != "$ans" ]; then
echo "Not a number"
elif [ "$number" -eq 0 ]; then
echo "Nothing was typed"
else
echo "$number is a fine number"
fi

expr "$x" : '(....)' | "$x"

expr 2 + 3 * 10

expr "$x" : '.*/(.*)' '|' "$x"

expr / : '.*/(.*)' '|' /

expr //$x : '.*/(.*)'

Precedence of the Operators

expr ( 2 + 3 ) * 10

+-------------------+
		    |Highest Precedence |
		    +-------------------+
		    |	expr : expr	|
		    +-------------------+
		    |	expr * expr	|
		    |	expr / expr	|
		    |	expr % expr	|
		    +-------------------+
		    |	expr + expr	|
		    |	expr - expr	|
		    +-------------------+
		    |	expr = expr	|
		    | expr gt; expr	|
		    | expr gt;= expr	|
		    | expr lt; expr	|
		    | expr lt;= expr	|
		    |	expr != expr	|
		    +-------------------+
		    | expr  expr	|
		    +-------------------+
		    |	expr  expr	|
		    +-------------------+
		    |Lowest Precedence	|
		    +-------------------+

Berkeley Extensions

match
substr
length

I hope I've given you some insight on how to use the expr command. Many people only know about the numeric calculation features. It isn't as powerful as sed or awk, but if it can do the job, you may get a performance gain because you are using an built-in function instead of an external program.

Bourne Shell -- Functions and argument checking

The original version of the Bourne shell didn't have functions. If you wanted to perform an operation more than once, you either had to duplicate the code, or create a new shell script. There is a slight penalty for each script called, as another process must be created. You also have to know where the script is, if it isn't in the path.

The C shell has aliases, but these are limited to one line, and parsing arguments is extremely confusing. The Bourne shell solved this problem with the concept of functions. Here is an example that counts from 1 to 10, incrementing variable A in a function:

#!/bin/sh

inc_A() {
# Increment A by 1
A=`expr $A + 1`
}
A=1
while [ $A -le 10 ]
do
echo $A
inc_A
done

inc_A() { A=`expr $A + 1`; }

Passing an argument to a function is simple: it is identical to the mechanism used to pass an argument to a shell script. All you have to do is remember that the positional arguments are relative to the function, not the script. That is, if you have the following script:

#!/bin/sh
func() {echo $1;}
func $2

Passing values by name

#!/bin/sh
inc() { eval $1=`expr $$1 + 1`; }

A=10
inc A
# variable A now has the value of 11

a=`expr $a + 1`

Exiting from a function

Suppose you want to return a value from a function? If it's a variable, just put the value in a variable. But that's not what I'm talking about. I've shown you how to use the exit status in commands like if and while. What happens if you create a function and use it in a if statement? You have two choices. Normally, the function returns with the exit status of the last command. If you want to control explicitly the value, the Bourne shell has a special command called return that sets the status value to the value specified. If no value is specified, the status of the last command is used.

You can write a simple script to loop forever:

always_true() { return 0;}

while always_true
do
echo "I just can't control myself."
echo 'Someone stop me, please!'
done

Checking the number of arguments

#!/bin/sh -x
arg1=${1:-a.out}
arg2=${2:-`pwd`}
arg3=${3:-$HOME}
mv $arg2/$arg1 $arg3

#!/bin/sh
file_to_be_moved="$1"
arg1=${file_to_be_moved:?"filename missing"}
arg2=${2:-`pwd`}
arg3=${3:-$HOME}
mv $arg2/$arg1 $arg3

1: filename missing

file_to_be_moved: filename missing

UNIX conventions for command line arguments

If possible, you should go along with the conventions. Most shell scripts do not follow all of the conventions. Perhaps a refresher course is a good idea. Still here? I'll be brief. Optional arguments always start with a hyphen, and are a single letter or number. If an option has a value following it, the space is optional. For example, if the "o" variable takes a value, the following two examples should do the same thing:

program -ofile
program -o file

program -a -b -c
program -c -b -a
program -ab -c
program -cb -a
program -cba
program -abc

program -- -a

Checking for optional arguments

I've given you a very complete collection of scripts that you can modify to handle your needs. There are many other ways to solve the problems presented here. There is no single best method to use. Hopefully, you now know several options, and can decide on the method best for you.

This document was translated by troff2html v0.21 on September 22, 2001.