Shell Portability and Born shell

Note: You might be better off forgetting all this silly noise about compatibility and using bash. Bash is now standard de-facto and is available of almost all enterprise flavors of Unix and commercial linuxes.

It is still not available on HP-UX 11 by default, but you can install it from a depo. Anyway even they provide bash with binaries available for all HP-UX versions.  It is actually much easier to install bash on all systems that struggle with shell compatibility questions.  Solaris, AIX and linuxes have bash installed out of the box and now bash in the natural least common denominator of shells.  Moreover bash 3.xx is pretty close to ksh93 and if you tested you scripts with it, in most cases the script should work OK.  That main difference is treatment of the last stage of pipeline, but now there is bash option via which you "enforce" ksh behaviour (which is actually the only rational behaviour ;-).

Originally sh was Born shell that has a separate implementation. Those days sh is often implemented as a special compilation of existing ksh version (or bash) and in most cases it does not make sense to use Born shell. You will be better off using bash

The second problem in writing portable script is that there are also many subtle differences in utilities provided and their location for various flavors of Unix. There are several ways to deal with this problem. One is to provide symbolic link to "most reasonable location", the second is to provide wrappers and the third that probably the most popular is to encode path and the name of the utility in shell variables.

Both the Bourne shell, and the Korn shell, can use the semicolon and the carriage return interchangeably in their syntax of the if, for, and while built-in commands.  When using the brackets ([ ]) within if commands, you must separate both inside ends of the brackets from the inside characters with a space.

Shell Script Porting Guidelines

Here is a semi-useless table from the FAQ that compares shells.  It is old and from purely academic point of view is incomplete as it does not include ksh93 which is in many respect the pinnacle of traditional Unix shells. But again you need to forget about academic discussion here: it is simpler to switch to bash then struggle with all this stupid complexity. Bash is not perfect but it works well enough to suit your needs. Sometime the best way to conquer obstacle is to go around it :-)

                                    sh   csh  ksh  bash tcsh zsh  rc   es
Job control                          N    Y    Y    Y    Y    Y    N    N
Aliases                              N    Y    Y    Y    Y    Y    N    N
Shell functions                      Y(1) N    Y    Y    N    Y    Y    Y
"Sensible" Input/Output redirection  Y    N    Y    Y    N    Y    Y    Y
Directory stack                      N    Y    Y    Y    Y    Y    F    F
Command history                      N    Y    Y    Y    Y    Y    L    L
Command line editing                 N    N    Y    Y    Y    Y    L    L
Vi Command line editing              N    N    Y    Y    Y(3) Y    L    L
Emacs Command line editing           N    N    Y    Y    Y    Y    L    L
Rebindable Command line editing      N    N    N    Y    Y    Y    L    L
User name look up                    N    Y    Y    Y    Y    Y    L    L
Login/Logout watching                N    N    N    N    Y    Y    F    F
Filename completion                  N    Y(1) Y    Y    Y    Y    L    L
Username completion                  N    Y(2) Y    Y    Y    Y    L    L
Hostname completion                  N    Y(2) Y    Y    Y    Y    L    L
History completion                   N    N    N    Y    Y    Y    L    L
Fully programmable Completion        N    N    N    N    Y    Y    N    N
Mh Mailbox completion                N    N    N    N(4) N(6) N(6) N    N
Co Processes                         N    N    Y    N    N    Y    N    N
Builtin artithmetic evaluation       N    Y    Y    Y    Y    Y    N    N
Can follow symbolic links invisibly  N    N    Y    Y    Y    Y    N    N
Periodic command execution           N    N    N    N    Y    Y    N    N
Custom Prompt (easily)               N    N    Y    Y    Y    Y    Y    Y
Sun Keyboard Hack                    N    N    N    N    N    Y    N    N
Spelling Correction                  N    N    N    N    Y    Y    N    N
Process Substitution                 N    N    N    Y(2) N    Y    Y    Y
Underlying Syntax                    sh   csh  sh   sh   csh  sh   rc   rc
Freely Available                     N    N    N(5) Y    Y    Y    Y    Y
Checks Mailbox                       N    Y    Y    Y    Y    Y    F    F
Tty Sanity Checking                  N    N    N    N    Y    Y    N    N
Can cope with large argument lists   Y    N    Y    Y    Y    Y    Y    Y
Has non-interactive startup file     N    Y    Y(7) Y(7) Y    Y    N    N
Has non-login startup file           N    Y    Y(7) Y    Y    Y    N    N
Can avoid user startup files         N    Y    N    Y    N    Y    Y    Y
Can specify startup file             N    N    Y    Y    N    N    N    N
Low level command redefinition       N    N    N    N    N    N    N    Y
Has anonymous functions              N    N    N    N    N    N    Y    Y
List Variables                       N    Y    Y    N    Y    Y    Y    Y
Full signal trap handling            Y    N    Y    Y    N    Y    Y    Y
File no clobber ability              N    Y    Y    Y    Y    Y    N    F
Local variables                      N    N    Y    Y    N    Y    Y    Y
Lexically scoped variables           N    N    N    N    N    N    N    Y
Exceptions                           N    N    N    N    N    N    N    Y

Key to the table above.

   Y      Feature can be done using this shell.
          
   N      Feature is not present in the shell.
          
   F      Feature can only be done by using the shells function
          mechanism.
          
   L      The readline library must be linked into the shell to enable
          this Feature.

NEWS CONTENTS

• 20061011 : IBM Redbooks Solaris to Linux Migration A Guide for System Administrators ( IBM Redbooks Solaris to Linux Migration A Guide for System Administrators, Oct 11, 2006 )

Old News ;-)

[Oct 11, 2006] IBM Redbooks Solaris to Linux Migration A Guide for System Administrators

IBM wants you to migrate from Solaris to Linux but sometimes it is better to migrate in opposite direction and the guide is useful for this purpose too :-). Still moving from ksh to bash makes sense.

16.3 Moving from ksh to bash

Migrating your sh and ksh scripts to bash is typically a straightforward process. However, there is a minor difference to be aware of. If you are using the read statement in your script, as shown in Example 16-1, the second line echo results in a blank line. This is a known issue in bash and applies to both single and multiple variable reads.

Example 16-1 Sample read statement

> echo "A B C" | read x y z

> echo $x $y $z

> _

Here are some suggested workarounds for the read command:

> read x y z < <(echo "A B C")

> echo $x $y $z

A B C

> _

Using awk

> x=`echo "A B C" | awk `{ print $2 }'`

> echo $x

B

> _

For more information about using bash, refer to the following Web site:

http://www.gnu.org/software/bash/

Recommended Links

Softpanorama Recommended

Top articles

Sites

• IBM Redbooks Solaris to Linux Migration A Guide for System Administrators
• Aix Bourne Shell Reference
• Examples of Bourne shell scripts
• Lucc's Shell Scripts
• The history of the Bourne shell. Sven Mascheck's page

Paul Jarc's software lintsh

Paul Jarc's software lintsh is a Bourne shell that optionally warns about suspicious or nonportable constructs. It is intended to help script authors write correct, portable scripts; it will also be suitable for use as /bin/sh. It does not exist yet, and it might never, or perhaps the warning functionality could be added to an existing shell. Regardless, this list of gotchas will be maintained, and you can get into the habit of coding to avoid them.

The following programs are known to be in use as /bin/sh, in addition to the /bin/sh programs maintained by OS vendors. Please let me know about any not listed here.

• bash (most Linux systems)
• pdksh (OpenBSD)
• zsh (Darwin, Mac OS X)
• ash (NetBSD)
• Solaris ksh - maybe?
• ksh88 - maybe?
• ksh-93 - maybe?

You can also contribute by emailing me suggestions for constructs to warn about. My experience is mostly with bash and pdksh, so information about issues with other shells is especially appreciated. I am not interested in how shells behave in interactive mode; scripts are only affected by differences in behavior in noninteractive mode. Here's the list of issues so far. (Some are bugs in particular versions; these will still be warned about as long as buggy installations are thought to be common, or as long as I forget to update this page.)

Related Links

• Sven Mascheck has a page about the history of the Bourne shell.
• The GNU autoconf manual has some useful tips for portable shell programming.

Constructs likely to indicate a programming error

• "IFS=whatever set $variable"; this setting of IFS will not be used to split $variable. Use "IFS=whatever; set $variable" instead.

Constructs meaningful to all shells, but with different meanings to different shells

• If an inherited environment variable is set to a new value but never explicitly exported within a script, external commands may see either the original inherited value (Solaris sh) or the new value (bash).
• bash automatically sets the following variables (clobbering any inherited value): $BASH, $BASH_VERSINFO, $BASH_VERSION, $DIRSTACK, $EUID, $GROUPS, $HISTCMD, $HOSTNAME, $HOSTTYPE, $IFS, $LINENO, $MACHTYPE, $OLDPWD, $OPTERR, $OPTIND, $OSTYPE, $PPID, $PWD, $RANDOM, $SECONDS, $SHELLOPTS, $SHLVL, $UID, $_.
• bash automatically sets the following variables if they are not already set: $COLUMNS, $HISTFILE, $HISTFILESIZE, $HISTSIZE, $LINES, $MAILCHECK, $PATH, $PS4, $SHELL, $TERM.
• bash automatically unsets $PS1 and $PS2.
• bash automatically exports the following variables: $HOSTNAME, $HOSTTYPE, $MACHTYPE, $OSTYPE, $PATH, $PWD, $SHELL, $SHLVL, $TERM, $_.
• bash treats $BASH_VERSINFO, $EUID, $PPID, $SHELLOPTS, and $UID as read-only.
• Solaris ksh automatically sets $SHELL (to /bin/sh) if it is not already set.
• Solaris sh does not allow $PATH or $MAILCHECK to be unset.
• The builtin "echo" command may treat backslashes in its arguments as literal backslashes (bash), or as escape characters (pdksh).
• The builtin "echo" command may accept options such as "-n" (bash), or may treat all arguments as data to print (Solaris sh).
• Solaris ksh does not fork for the last command in the last pipeline in a script or subshell.
• Solaris sh does not fork for the last command in the last pipeline in a subshell.
• "$*" may expand to the positional parameters separated by the first character of $IFS, or by the empty string if $IFS is empty (bash, pdksh, Solaris ksh), or it may expand to the positional parameters separated by spaces (Solaris sh).
• bash and pdksh use $IFS for word splitting only for the results of unquoted expansions (variable expansions, command substitution, etc.). Solaris sh uses it for all unquoted strings. Solaris ksh uses it for the unquoted parts of any word which includes a (quoted or unquoted) expansion.
• When "\"" appears in a here-document, pdksh interprets the backslash as an escape character and removes it. bash and Solaris sh preserve the backslash. Workaround: backslash-escape the backslash.
• "var=value builtin-command" may leave the variable set after the builtin command completes (pdksh, Solaris sh), or may revert it to its previous state for subsequent commands (bash), depending on which builtin command is used.
• "var=value exec cmd" may set $var in the environment for cmd (bash, pdksh) or not (Solaris sh). Workaround: "exec env var=value cmd".
• "var= shell_function" may make $var unset during the call to the function (bash before version 2.05b), may set it to the empty string during the call (bash 2.05b and later, pdksh) or may not affect $var at all during the call (Solaris sh).
• If var is already unset, "unset var" may give exit status 0 (bash 2.05b and later, Solaris sh) or nonzero (bash before version 2.05b, pdksh, Solaris ksh).
• ". directory" may fail with an error message (bash) or may be a successful no-op (pdksh).
• bash allows arbitrary file descriptors to be redirected. pdksh doesn't redirect file descriptors larger than 9; any digit strings longer than a single character are treated as a command or argument, even if followed immediately by ">" or "<".
• Solaris sh will lose its script fd if a redirection in the script happens to use that fd. bash dups the script fd before performing the redirection. pdksh initially moves the script to an fd larger than 9, so it cannot be redirected.
• In bash, "command &> file" runs command with standard output and error redirected to file. In pdksh, it runs command in the background and then truncates file, as if it were written "command & > file".
• bash accepts both "!" and "^" to negate character classes in pattern matching; pdksh accepts only "!".
• pdksh and bash treat an unquoted "^" as a non-special character; Solaris sh treats it as a metacharacter.
• Solaris sh forks for compound commands with redirections such as "while read var; do something; done < file", so variable assignments and exit behave differently (although errors still cause the top-level shell to exit if set -e is in effect). bash and pdksh do not fork. As a workaround, the compound command can be wrapped in a shell function, and the function can be invoked with redirections; this will not cause Solaris sh to fork.
• For an if...elif...fi chain, any redirections appplied to the final fi may take effect only for the final then clause (and the accompanying elif condition, if there is one) (Solaris sh), or for the entire compound command (bash). Workaround: put the whole compound command inside {...}, and move the redirections outside the braces.
• Even when set -e is in effect, "false && true" does not cause Solaris sh to exit.
• Even when set -e is in effect, "foo() { return 1; }; foo" does not cause Solaris sh to exit.
• When set -e is in effect, a shell function that returns with a nonzero status always causes BSD/OS sh to exit, even if the call is the condition of an if statement, etc. Workaround: call the shell function in a subshell.
• When set -e is in effect, "foo() { true; false; }; foo || :" causes Solaris sh to exit.
• When set -e is in effect, eval false may cause the shell to exit unconditionally, (pdksh, FreeBSD sh), or may not, depending on the context of the eval command (bash). Workaround: wrap the eval in a subshell.
• Even when set -e is not in effect, a builtin command with failing redirections, called from eval, may cause the shell to exit (FreeBSD sh, NetBSD sh) or not (bash, pdksh, Solaris sh). It may even depend on which builtin command is used - bash exits for :, but not for true.
• When set -e is in effect and a subshell command exits nonzero, Solaris sh and ksh and FreeBSD sh exit; bash, FreeBSD ksh, and NetBSD sh and ksh do not exit. pdksh exits in some circumstances but not others.
• If the test command is a builtin and returns false, the shell may exit when set -e is in effect (pdksh, bash) or not (Solaris sh).
• The "test" builtin command may treat the following as operators (bash) or as plain strings (Solaris sh): ">", "<", "-G", "-O", "-S", "-e", "-ef", "-nt", "-o" "-ot", "==".
• "test '!' = '!'" may treat "=" as a binary operator (bash, pdksh), or may treat the first "!" as negation.
• Variable names and shell function names may share a single namespace (Solaris sh) or have separate namespaces (bash).
• $? may be reset upon the appearance of redirections (Free/NetBSD sh), or only after whole commands.
• Failed redirections (e.g., reading from a nonexistent file) may cause the shell to exit (pdksh), or to set $? to nonzero for the command (bash).
• A failing cd command may cause the shell to exit even when set -e is not in effect (Solaris sh), or may return a nonzero exit status (bash, pdksh).
• When set -e is in effect, a failing command in backticks appearing as an argument of another command, as in "echo `false`", may cause the shell to exit (Solaris sh), or not (bash, pdksh, Solaris ksh). Workaround: use backticks only in variable assignments. All shells exit if such a command exits nonzero: "var=`false`; echo "$var"".
• "!", "[[", "function" and "time" may be shell keywords, having special effects on parsing (bash), or may be treated as ordinary external command names (Solaris sh).
• The following commands may be shell builtins or may be treated as ordinary external command names: "alias", "bind", "builtin", "command", "compgen", "complete", "declare", "dirs", "disown", "enable", "fc", "getconf", "help", "hist", "history", "let", "local", "logout", "newgrp", "popd", "print", "printf", "pushd", "shopt", "sleep", "stop", "typeset", "unalias", "whence".
• "$'foo\nbar'" may be expanded as "foo<newline>bar" (bash), or plainly quoted as "$foo\nbar" (Solaris sh).
• "a{b,c}d" may expand to "abd acd" (bash), or may be treated literally (Solaris sh).
• "`< file`" may expand to the contents of file (bash), or to an empty string (Solaris sh).
• A second invocation argument beginning with "-" may be treated as an option/flag (bash), or as a script filename (Solaris sh).
• A match pattern like "[[:alnum:]]", "[[=c=]]", or "[[.symbol.]]" may be treated as an extension pattern (bash) or as a simple character-class pattern followed by a literal "]" (pdksh).
• An unquoted "~" in certain contexts may be subject to tilde expansion (bash), or may be treated literally (Solaris sh).
• "set --" may be a no-op (Solaris sh), or may unset all positional parameters (bash, pdksh). To unset all positional parameters portably, use "set x && shift".
• If there are no arguments, ""$@"" may expand to a single empty argument (some older sh implementations) or to no arguments (bash, pdksh, Solaris sh, zsh). This is commonly worked around by using "${1+"$@"}". However, this workaround fails for zsh: each argument will be subjected to word splitting. To avoid this, define this global alias before using the workaround:

  case $ZSH_VERSION in ?*) alias -g '${1+"$@"}="$@"';; esac
  

  Alternatively, explicitly check for arguments and use separate command lines:

  case $# in 0) foo;; *) foo "$@";; esac
  

  But this kind of code is harder to maintain.
• If a double-quoted positional parameter is used in a case pattern, then any wildcard characters in its value may be interpreted either as literal characters (bash, pdksh, Solaris sh, OpenBSD sh) or as wildcards (FreeBSD sh, NetBSD sh before NetBSD 2.0). To force the literal interpretation, assign the value of the positional parameter to a named parameter, and use the named parameter in the case pattern:

  var=$1; case foo in "$var") ...;; esac
  

• A case statement in which none of the patterns match may return successfully (bash, pdksh) or may preserve $? as the exit code of the previous command (Solaris sh). Workaround: include a final pattern clause like "*) :;;" to ensure there is a match.
• A for loop with an empty list of iteration values (such as "for var in $empty ...") may return successfully (bash, pdksh) or may preserve $? as the exit code of the previous command (Solaris sh). Workaround: insert a ":" command before the for loop to ensure that the status of the loop will be 0 if it never iterates.
• A wildcard pattern (used as an argument, not as a case pattern) ending in "*/" may expand to a list of directories (bash, pdksh) or may be preserved as if it were quoted (Solaris sh). Workaround: use "...*/.".
• When invoked as "sh script-basename" the script may be searched for only in the current directory (pdksh; Solaris, NetBSD, FreeBSD, OpenBSD sh), or in the current directory followed by $PATH (bash), or in $PATH followed by the current directory (Solaris ksh).

Constructs not meaningful to some shells

These will also be erroneous for lintsh; no separate warning will be necessary. These include:

• "for i; do ...; done" is a syntax error for Solaris sh. However, "for i do ...; done" works portably.
• "$(command)" is a syntax error for Solaris sh. However, "`command`" works portably.
• A missing final quote, as in "echo 'foo", is tolerated by Solaris sh, but not by pdksh or bash.
• "${var-multiple words}" (also with + instead of -) is a syntax error for Solaris sh. Workaround: "tmp='multiple words'; echo ${var-$tmp}"
• In bash, "command >& file" runs command with standard output and standard error redirected to file. In pdksh, it is a syntax error. Portable syntax: "command > file 2>&1"

Random Findings

Solaris Test command

/usr/bin/test [condition]
condition


sh

if condition ; then action ; fi
if condition ; then action ; else action2 ; fi
if condition ; then action ; elif condition2 ; then action2 ;� ; fi
if condition ; then action ; elif condition2 ; then action2 ;� ; else action3 ; fi
test condition
[condition]


csh

if ( condition ) then
action
else if ( condition2 ) then
action2
else
action3
endif
if ( condition ) [action]


ksh

if condition ; then action ; fi
if condition ; then action ; else action2 ; fi
if condition ; then action ; elif condition2 ; then action2 ;� ; fi
if condition ; then action ; elif condition2 ; then action2 ;� ; else action3 ; fi
test condition
[condition]

DESCRIPTION

/usr/bin/test

The test utility evaluates the condition and indicates the result of the evaluation by its exit status. An exit status of zero indicates that the condition evaluated as true and an exit status of 1 indicates that the condition evaluated as false.

In the second form of the utility, which uses [ ] rather than test, the square brackets must be separate arguments and condition is optional.

See largefile(5) for the description of the behavior of test when encountering files greater than or equal to 2 Gbyte ( 2³¹ bytes).

sh

The condition following if is executed and, if it returns a 0 exit status, the action following the first then is executed. Otherwise, the condition2 following elif is executed and, if its value is 0, the action2 following the next then is executed. Failing the if and elif conditions, the else action3 is executed. If no else action or then action is executed, the if command returns a 0 exit status. Any number of elif . . . then . . . branching pairs are allowed, but only one else.

test evaluates the condition condition and, if its value is true, sets exit status to 0; otherwise, a non-zero (false) exit status is set; test also sets a non-zero exit status if there are no arguments. When permissions are tested, the effective user ID of the process is used.

All operators, flags, and brackets (brackets used as shown in the second SYNOPSIS line) must be separate arguments to the test command; normally these items are separated by spaces.

Primitives:

The following primitives are used to construct condition:

-r filename

True if filename exists and is readable.

-w filename

True if filename exists and is writable.

-x filename

True if filename exists and is executable.

-f filename

True if filename exists and is a regular file. Alternatively, if /usr/bin/sh users specify /usr/ucb before /usr/bin in their PATH environment variable, then test will return true if filename exists and is (not-a-directory). This is also the default for /usr/bin/csh users.

-d filename

True if filename exists and is a directory.

-h filename

True if filename exists and is a symbolic link. With all other primitives (except -L filename), the symbolic links are followed by default.

-c filename

True if filename exists and is a character special file.

-b filename

True if filename exists and is a block special file.

-p filename

True if filename exists and is a named pipe (fifo).

-u filename

True if filename exists and its set-user- ID bit is set.

-g filename

True if filename exists and its set-group- ID bit is set.

-k filename

True if filename exists and its sticky bit is set.

-s filename

True if filename exists and has a size greater than zero.

-t [ fildes ]

True if the open file whose file descriptor number is fildes (1 by default) is associated with a terminal device.

-z s1

True if the length of string s1 is zero.

-n s1

True if the length of the string s1 is non-zero.

s1 = s2

True if strings s1 and s2 are identical.

s1 != s2

True if strings s1 and s2 are not identical.

s1

True if s1 is not the null string.

n1 -eq n2

True if the integers n1 and n2 are algebraically equal.

n1 -ne n2

True if the integers n1 and n2 are not algebraically equal.

n1 -gt n2

True if the integer n1 is algebraically greater than the integer n2.

n1 -ge n2

True if the integer n1 is algebraically greater than or equal to the integer n2.

n1 -lt n2

True if the integer n1 is algebraically less than the integer n2.

n1 -le n2

True if the integer n1 is algebraically less than or equal to the integer n2.

-L filename

True if filename exists and is a symbolic link. With all other primitives (except -h filename), the symbolic links are followed by default.

Operators:

These primaries may be combined with the following operators:

!

Unary negation operator.

-a

Binary and operator.

-o

Binary or operator (-a has higher precedence than -o).

(condition)

Parentheses for grouping. Notice also that parentheses are meaningful to the shell and, therefore, must be quoted.

The not-a-directory alternative to the -f option is a transition aid for BSD applications and may not be supported in future releases.

The -L option is a migration aid for users of other shells which have similar options and may not be supported in future releases.

If you test a file you own (the -r -w or -x tests), but the permission tested does not have the owner bit set, a non-zero (false) exit status will be returned even though the file may have the group or other bit set for that permission. The correct exit status will be set if you are super-user.

The = and != operators have a higher precedence than the -r through -n operators, and = and != always expect arguments; therefore, = and != cannot be used with the -r through -n operators.

If more than one argument follows the -r through -n operators, only the first argument is examined; the others are ignored, unless a -a or a -o is the second argument.

csh

With the multi-line form of if:

if condition is true, the action up to the first else or then is executed. Otherwise, if else if condition2 is true, the action2 between the else if and the following else or then is executed. Otherwise, the action3 between the else and the endif is executed.

The if must appear alone on its input line or after an else. Only one endif is needed, but it is required. The words else and endif must be the first nonwhite characters on a line. Any number of else if . . . then . . . branching pairs are allowed, but only one else.

With the one-line form of if, there are no else, then, or endif keywords:

if the specified condition evaluates to true, the single action with arguments is executed. Variable substitution on action happens early, at the same time it does for the rest of the if command. action must be a simple command, not a pipeline, a command list, or a parenthesized command list. Note that I/O redirection occurs even if condition is false, when action is not executed (this is a bug).

ksh

The condition following if is executed and, if it returns an exit status of 0, the action following the first then is executed. Otherwise, the condition2 following elif is executed and, if its value is 0, the action2 following the next then is executed. Failing that, the else action3 is executed. If no else action or then action is executed, then the if command returns an exit status of 0. Any number of elif . . . then . . . branching pairs are allowed, but only one else.

For a description of the test built-in, see the ksh(1) sections Conditional Expressions and Arithmetic Evaluation as well as the (sh) Bourne shell's test built-in above.

[ condition ] evaluates file attributes, string comparisons, and compound "and" or "or" conditions.

OPERANDS

All operators and elements of primaries must be presented as separate arguments to the test utility.

The following primaries can be used to construct condition:

-a file

True, if file exists.

-b file

True if file exists and is a block special file.

-c file

True if file exists and is a character special file.

-d file

True if file exists and is a directory.

-e file

True if file exists.

-f file

True if file exists and is a regular file.

-g file

True if file exists and its set group ID flag is set.

-k file

True, if file exists and is has its sticky bit set.

-n string

True if the length of string is non-zero.

-o option

True, if option named option is on.

-p file

True if file is a named pipe (FIFO).

-r file

True if file exists and is readable.

-s file

True if file exists and has a size greater than zero.

-t file_descriptor

True if the file whose file descriptor number is file_descriptor is open and is associated with a terminal.

-u file

True if file exists and its set-user-ID flag is set.

-w file

True if file exists and is writable. True will indicate only that the write flag is on. The file will not be writable on a read-only file system even if this test indicates true.

-x file

True if file exists and is executable. True will indicate only that the execute flag is on. If file is a directory, true indicates that file can be searched.

-z string

True if the length of string string is zero.

-L file

True, if file exists and is a symbolic link.

-O file

True, if file exists and is owned by the effective user ID of this process.

-G file

True, if file exists and its group matches the effective group ID of this process.

-S file

True, if file exists and is a socket.

file1-nt file2

True, if file1 exists and is newer than file2.

file1-ot file2

True, if file1 exists and is older than file2.

file1-ef file2

True, if file1 and file2 exist and refer to the same file.

string

True if the string string is not the null string.

string = pattern

True, if string matches pattern.

string != pattern

True, if string does not match pattern.

string1=string2

True if the strings string1 and string2 are identical.

string1! =string2

True if the strings string1 and string2 are not identical.

string1 < string2

True, if string1 comes before string2 based on ASCII value of their characters.

string1 > string2

True, if string1 comes after string2 based on ASCII value of their characters.

n1 -eq n2

True if the integers n1 and n2 are algebraically equal.

n1 -ne n2"

True if the integers n1 and n2 are not algebraically equal.

n1 -gt n2"

True if the integer n1 is algebraically greater than the integer n2.

n1 -ge n2"

True if the integer n1 is algebraically greater than or equal to the integer n2.

n1 -lt n2"

True if the integer n1 is algebraically less than the integer n2.

n1 -le n2"

True if the integer n1 is algebraically less than or equal to the integer n2.

These primaries can be combined with the following operator:

!condition

True if condition is false.

The primaries with two elements of the form:

---

-primary_operator  primary_operand  

---

are known as unary primaries. The primaries with three elements in either of the two forms:

---

primary_operand  -primary_operator  primary_operand
primary_operand  primary_operator   primary_operand

---

are known as binary primaries.

The algorithm for determining the precedence of the operators and the return value that will be generated is based on the number of arguments presented to test. (However, when using the [. . .] form, the right-bracket final argument will not be counted in this algorithm.)

In the following list, $1, $2, $3 and $4 represent the arguments presented to test.

0 arguments:

Exit false (1).

1 argument:

Exit true (0) if $1 is not null; otherwise, exit false.

2 arguments:

• If $1 is !, exit true if $2 is null, false if $2 is not null.
• If $1 is a unary primary, exit true if the unary test is true, false if the unary test is false.
• Otherwise, produce unspecified results.

3 arguments:

• If $2 is a binary primary, perform the binary test of $1 and $3.
• If $1 is !, negate the two-argument test of $2 and $3.
• Otherwise, produce unspecified results.

4 arguments:

• If $1 is !, negate the three-argument test of $2, $3, and $4.
• Otherwise, the results are unspecified.

USAGE

Scripts should be careful when dealing with user-supplied input that could be confused with primaries and operators. Unless the application writer knows all the cases that produce input to the script, invocations like:

test "$1" -a "$2"

should be written as:

test "$1" && test "$2"

to avoid problems if a user supplied values such as $1 set to ! and $2 set to the null string. That is, in cases where maximal portability is of concern, replace:

test expr1 -a expr2

with:

test expr1 && test expr2

and replace:

test expr1 -o expr2

with:

test expr1 | | test expr2

but note that, in test, -a has higher precedence than -o while && and | | have equal precedence in the shell.

Parentheses or braces can be used in the shell command language to effect grouping.

Parentheses must be escaped when using sh; for example:

test \( expr1 -a expr2 \) -o expr3

This command is not always portable outside XSI-conformant systems. The following form can be used instead:

( test expr1 && test expr2 ) | | test expr3

The two commands:

test "$1"
test ! "$1"

could not be used reliably on some historical systems. Unexpected results would occur if such a string condition were used and $1 expanded to !, ( or a known unary primary. Better constructs are:

test -n "$1"
test -z "$1"

respectively.

Historical systems have also been unreliable given the common construct:

test "$response" = "expected string"

One of the following is a more reliable form:

test "X$response" = "Xexpected string"
test "expected string" = "$response"

Note that the second form assumes that expected string could not be confused with any unary primary. If expected string starts with -, (, ! or even =, the first form should be used instead. Using the preceding rules without the marked extensions, any of the three comparison forms is reliable, given any input. (However, note that the strings are quoted in all cases.)

Because the string comparison binary primaries, = and !=, have a higher precedence than any unary primary in the >4 argument case, unexpected results can occur if arguments are not properly prepared. For example, in

test -d $1 -o -d $2

If $1 evaluates to a possible directory name of =, the first three arguments are considered a string comparison, which causes a syntax error when the second -d is encountered. is encountered. One of the following forms prevents this; the second is preferred:

test \( -d "$1" \) -o \( -d "$2" \)
test -d "$1" | | test -d "$2"

Also in the >4 argument case,

test "$1" = "bat" -a "$2" = "ball"

Syntax errors will occur if $1 evaluates to ( or !. One of the following forms prevents this; the third is preferred:

test "X$1" = "Xbat" -a "X$2" = "Xball"
test "$1" = "bat" && test "$2" = "ball"
test "X$1" = "Xbat" && test "X$2" = "Xball"

EXAMPLES

In the if command examples, three conditions are tested, and if all three evaluate as true or successful, then their validities are written to the screen. The 3 tests are:

• if a variable set to 1 is greater than 0,
• if a variable set to 2 is equal to 2, and
• if the word "root" is included in the text file /etc/passwd.

/usr/bin/test

Example 1 Using /usr/bin/test

Perform a mkdir if a directory does not exist:

test ! -d tempdir && mkdir tempdir

Wait for a file to become non-readable:

while test -r thefile
do
   sleep 30
done
echo'"thefile" is no longer readable'

Perform a command if the argument is one of three strings (two variations):

if [ "$1" = "pear" ] | | [ "$1" = "grape" ] | | [ "$1" = "apple" ]
then
    command
fi
case "$1" in
    pear|grape|apple) command;;
esac

The test built-in

The two forms of the test built-in follow the Bourne shell's if example.

Example 2 Using the sh built-in


ZERO=0 ONE=1 TWO=2 ROOT=root

if  [ $ONE -gt $ZERO ]

[ $TWO -eq 2 ]

grep $ROOT  /etc/passwd >&1 > /dev/null  # discard output

then

    echo "$ONE is greater than 0, $TWO equals 2, and $ROOT is a user-name
          in the password file"

else

    echo "At least one of the three test conditions is false"        
fi

Example 3 Using the test built-in

test `grep $ROOT /etc/passwd >&1 /dev/null`   # discard output 

echo $?    # test for success
[ `grep nosuchname /etc/passwd >&1 /dev/null` ]

echo $?    # test for failure

ksh

Example 5 Using the ksh built-in

ZERO=0 ONE=1 TWO=$((ONE+ONE)) ROOT=root        
if  ((ONE > ZERO))            #  arithmetical comparison
[[ $TWO = 2 ]]                #  string comparison
[ `grep $ROOT  /etc/passwd >&1 /dev/null` ] # discard output       
then 
     echo "$ONE is greater than 0, $TWO equals 2, and $ROOT is a user-name 
            in the password file"

else
     echo "At least one of the three test conditions is false"
fi

The Korn shell will also accept the syntax of both the if command and the test command of the Bourne shell.

When using the brackets ([ ]) within if commands, you must separate both inside ends of the brackets from the inside characters with a space.

ENVIRONMENT VARIABLES

See environ(5) for descriptions of the following environment variables that affect the execution of test: LC_CTYPE, LC_MESSAGES, and NLSPATH.

EXIT STATUS

The following exit values are returned:

0

condition evaluated to true.

1

condition evaluated to false or condition was missing.

>1

An error occurred.

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 12, 2019