Sequences of commands in Unix shell

Every UNIX command including shell functions, returns an integer code to its calling process - the shell when it finishes. This is called the exit status. Unlike Boolean logic in Unix 0 is assumed to be the "OK" (true) exit status, while anything else (1 to 255) usually denotes an error.

Shell if statement checks the exit status of the last statement in the list following the if keyword (The list is usually just a single statement.) If the status is 0, the condition evaluates to true; if it is anything else, the condition is considered false. The same is true for each condition attached to an elif statement (if any).

This enables us to write code of the form:

if command ran successfully
then
    normal processing
else
    error processing
fi

function pushd {                # push current directory onto stack
    dirname=$1
    if cd ${dirname:?"missing directory name."}   # if cd was successful
    then
        DIRSTACK="$dirname ${DIRSTACK:-$PWD}"
        print $DIRSTACK
    else
        print "still in $PWD."
    fi
}

The call to cd is nowperformed inside an if construct. If cd is successful, it will return 0; the next two lines of code are run, finishing the pushd operation. But if the cd fails, it returns with exit status 1, and pushd will print a message saying that you haven't gone anywhere.

You can usually rely on built-in commands and standard UNIX utilities to return appropriate exit statuses, but what about your own shell scripts and functions? For example, what if you wrote a cd function that overrides the built-in command?

Let's say you have the following code in your .profile or environment file:

function _cd {
    "cd" $*
    print $OLDPWD -> $PWD
}
alias cd=_cd

The function _cd simply changes directories and prints a message saying where you were and where you are now. Because functions have lower priority than built-in commands in the shell's order of command lookup, we need to define cd itself as an alias so that it overrides the built-in cd.

The function calls the built-in cd command, but notice that it's surrounded in double quotes: that prevents the shell from looking it up as an alias. (This may seem like a kludge in the aliasing mechanism, but it's really just a ramification of the shell's command-line processing rules)

If it did find cd as an alias, the shell would go into an "infinite recursion" in which the alias is expanded to _cd, which runs the function, which calls cd, which the shell expands to the alias again, etc.

Anyway, we want this function to return the same exit status that the built-in cd returns. The problem is that the exit status is reset by every command, so it "disappears" if you don't save it immediately. In this function, the built-in cd's exit status disappears when the print statement runs (and sets its own exit status).

Therefore, we need to save the status that cd sets and use it as the entire function's exit status. Two shell features we haven't seen yet provide the way. First is the special shell variable ?, whose value ($?) is the exit status of the last command that ran. For example:

cd baddir
print $?

causes the shell to print 1, while:

cd gooddir
print $?

causes the shell to print 0.

Standard sequence of sell command presuppose that each command ends end of the line or with semicolon. In this case commands execute sequentially independently whether previous command succeed or fail. But there is also a way to make the execution of the second command dependent on the success of the first. It is called conditional execution.

Conditional Execution && and ||

One of the more obscure parts of Korn shell syntax allows you to combine exit statuses logically, so that you can test more than one thing at a time:

• statement1 && statement2   means, "execute statement2 if statement1 succed"

• statement1 || statement2  means, "execute statement2 if statement1 fail"

In both cases it's useful to think about them "short-circuit and" and "short-circuit or," respectively:

They can be used in if statement too:

if statement1 && statement2
then
    ...
fi

Or

if statement1 || statement2
then
    ...
fi

Typical usage is  "cd directory && rm -rf *" (not "cd directory; rm -rf *": If the directory in question does not exist, this command can result in really unintended consequences)

The operator "||" executes the second command only if the first one failed, but it is used is shell much less.  It is more often used is Perl to check if file opened successfully:

open(SYSIN, "$myfile") || die (" cannot open $myfile\n");

You can group commands that are affected by && or || by enclosing them in braces. You have to type a semicolon after the last command of the group. This feature is used relatively rarely, it is needed mainly for putting a sequence of commands in the background (i.e. letting it be executed without blocking the terminal). An example is the UNIX way of reminding yourself when your tea is ready:

{ cd directory && rm -rf * } > ~/Logs/deletion.log

Old News ;-)

List Constructs

The "and list" and "or list" constructs provide a means of processing a number of commands consecutively. These can effectively replace complex nested if/then or even case statements. Note that the exit status of an "and list" or an "or list" is the exit status of the last command executed.

and list

 

1 command-1 && command-2 && command-3 && ... command-n

Each command executes in turn provided that the previous command has given a return value of true. At the first false return, the command chain terminates (the first command returning false is the last one to execute). 

---

Example 3-87. Using an "and list" to test for command-line arguments

1 #!/bin/bash 2  3 # "and list" 4  5 if [ ! -z $1 ] && echo "Argument #1 = $1" && [ ! -z $2 ] && echo "Argument #2 = $2" 6 then 7  echo "At least 2 arguments to script." 8  # All the chained commands return true. 9 else 10  echo "Less than 2 arguments to script." 11  # At least one of the chained commands returns false. 12 fi 13 # Note that "if [ ! -z $1 ]" works, but its supposed equivalent, 14 # "if [ -n $1 ]" does not. This is a bug, not a feature. 15  16  17 # This accomplishes the same thing, coded using "pure" if/then statements. 18 if [ ! -z $1 ] 19 then 20  echo "Argument #1 = $1" 21 fi 22 if [ ! -z $2 ] 23 then 24  echo "Argument #2 = $2" 25  echo "At least 2 arguments to script." 26 else 27  echo "Less than 2 arguments to script." 28 fi 29 # It's longer and less elegant than using an "and list". 30  31  32 exit 0

---

or list

 

1 command-1 || command-2 || command-3 || ... command-n

Each command executes in turn for as long as the previous command returns false. At the first true return, the command chain terminates (the first command returning true is the last one to execute). This is obviously the inverse of the "and list". 

---

Example 3-88. Using "or lists" in combination with an "and list"

1 #!/bin/bash 2  3 # "Delete", not-so-cunning file deletion utility. 4 # Usage: delete filename 5  6 if [ -z $1 ] 7 then 8  file=nothing 9 else 10  file=$1 11 fi 12 # Fetch file name (or "nothing") for deletion message. 13  14  15 [ ! -f $1 ] && echo "$1 not found. Can't delete a nonexistent file." 16 # AND LIST, to give error message if file not present. 17  18 [ ! -f $1 ] || ( rm -f $1; echo "$file deleted." ) 19 # OR LIST, to delete file if present. 20 # ( command1 ; command2 ) is, in effect, an AND LIST variant. 21  22 # Note logic inversion above. 23 # AND LIST executes on true, OR LIST on false. 24  25 [ ! -z $1 ] || echo "Usage: `basename $0` filename" 26 # OR LIST, to give error message if no command line arg (file name). 27  28 exit 0

---

Clever combinations of "and" and "or" lists are possible, but the logic may easily become convoluted and require extensive debugging.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 15, 2008