xcu_chap02.html

IEEE 1003.1-2003, Single Unix Specification v3

<p>echoing <tt>"2"</tt> to standard error or <tt>"22"</tt> to standard output are no longer portable. However, the file descriptor
number must still be delimited from the preceding text. For example:</p>

<blockquote>
<pre>
<tt>cat file2&gt;foo
</tt>
</pre>
</blockquote>

<p>writes the contents of <b>file2</b>, not the contents of <b>file</b>.</p>

<p>The <tt>"&gt;|"</tt> format of output redirection was adopted from the KornShell. Along with the <i>noclobber</i> option, <a
href="../utilities/set.html"><i>set</i></a> <b>-C</b>, it provides a safety feature to prevent inadvertent overwriting
of existing files. (See the RATIONALE for the <a href="../utilities/pathchk.html"><i>pathchk</i></a> utility for why this step was
taken.) The restriction on regular files is historical practice.</p>

<p>The System&nbsp;V shell and the KornShell have differed historically on pathname expansion of <i>word</i>; the former never
performed it, the latter only when the result was a single field (file). As a compromise, it was decided that the KornShell
functionality was useful, but only as a shorthand device for interactive users. No reasonable shell script would be written with a
command such as:</p>

<blockquote>
<pre>
<tt>cat foo &gt; a*
</tt>
</pre>
</blockquote>

<p>Thus, shell scripts are prohibited from doing it, while interactive users can select the shell with which they are most
comfortable.</p>

<p>The construct <tt>"2&gt;&amp;1"</tt> is often used to redirect standard error to the same file as standard output. Since the
redirections take place beginning to end, the order of redirections is significant. For example:</p>

<blockquote>
<pre>
<tt>ls &gt; foo 2&gt;&amp;1
</tt>
</pre>
</blockquote>

<p>directs both standard output and standard error to file <b>foo</b>. However:</p>

<blockquote>
<pre>
<tt>ls 2&gt;&amp;1 &gt; foo
</tt>
</pre>
</blockquote>

<p>only directs standard output to file <b>foo</b> because standard error was duplicated as standard output before standard output
was directed to file <b>foo</b>.</p>

<p>The <tt>"&lt;&gt;"</tt> operator could be useful in writing an application that worked with several terminals, and occasionally
wanted to start up a shell. That shell would in turn be unable to run applications that run from an ordinary controlling terminal
unless it could make use of <tt>"&lt;&gt;"</tt> redirection. The specific example is a historical version of the pager <a href=
"../utilities/more.html"><i>more</i></a>, which reads from standard error to get its commands, so standard input and standard
output are both available for their usual usage. There is no way of saying the following in the shell without <tt>"&lt;&gt;"</tt>
:</p>

<blockquote>
<pre>
<tt>cat food | more - &gt;/dev/tty03 2&lt;&gt;/dev/tty03
</tt>
</pre>
</blockquote>

<p>Another example of <tt>"&lt;&gt;"</tt> is one that opens <b>/dev/tty</b> on file descriptor 3 for reading and writing:</p>

<blockquote>
<pre>
<tt>exec 3&lt;&gt; /dev/tty
</tt>
</pre>
</blockquote>

<p>An example of creating a lock file for a critical code region:</p>

<blockquote>
<pre>
<tt>set -C
until    2&gt; /dev/null &gt; lockfile
do       sleep 30
done
set +C
</tt><i>perform critical function</i><tt>rm lockfile
</tt>
</pre>
</blockquote>

<p>Since <b>/dev/null</b> is not a regular file, no error is generated by redirecting to it in <i>noclobber</i> mode.</p>

<p>Tilde expansion is not performed on a here-document because the data is treated as if it were enclosed in double quotes.</p>

<h5><a name="tag_02_02_07_01"></a>Redirecting Input</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_02_07_02"></a>Redirecting Output</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_02_07_03"></a>Appending Redirected Output</h5>

<p>Note that when a file is opened (even with the O_APPEND flag set), the initial file offset for that file is set to the beginning
of the file. Some historic shells set the file offset to the current end-of-file when <b>append</b> mode shell redirection was
used, but this is not allowed by IEEE&nbsp;Std&nbsp;1003.1-2001.</p>

<h5><a name="tag_02_02_07_04"></a>Here-Document</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_02_07_05"></a>Duplicating an Input File Descriptor</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_02_07_06"></a>Duplicating an Output File Descriptor</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_02_07_07"></a>Open File Descriptors for Reading and Writing</h5>

<p>There is no additional rationale provided for this section.</p>

<h4><a name="tag_02_02_08"></a>Exit Status and Errors</h4>

<h5><a name="tag_02_02_08_01"></a>Consequences of Shell Errors</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_02_08_02"></a>Exit Status for Commands</h5>

<p>There is a historical difference in <a href="../utilities/sh.html"><i>sh</i></a> and <i>ksh</i> non-interactive error behavior.
When a command named in a script is not found, some implementations of <a href="../utilities/sh.html"><i>sh</i></a> exit
immediately, but <i>ksh</i> continues with the next command. Thus, the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001
says that the shell &quot;may&quot; exit in this case. This puts a small burden on the programmer, who has to test for successful
completion following a command if it is important that the next command not be executed if the previous command was not found. If
it is important for the command to have been found, it was probably also important for it to complete successfully. The test for
successful completion would not need to change.</p>

<p>Historically, shells have returned an exit status of 128+ <i>n</i>, where <i>n</i> represents the signal number. Since signal
numbers are not standardized, there is no portable way to determine which signal caused the termination. Also, it is possible for a
command to exit with a status in the same range of numbers that the shell would use to report that the command was terminated by a
signal. Implementations are encouraged to choose exit values greater than 256 to indicate programs that terminate by a signal so
that the exit status cannot be confused with an exit status generated by a normal termination.</p>

<p>Historical shells make the distinction between &quot;utility not found&quot; and &quot;utility found but cannot execute&quot; in their error
messages. By specifying two seldomly used exit status values for these cases, 127 and 126 respectively, this gives an application
the opportunity to make use of this distinction without having to parse an error message that would probably change from locale to
locale. The <a href="../utilities/command.html"><i>command</i></a>, <a href="../utilities/env.html"><i>env</i></a>, <a href=
"../utilities/nohup.html"><i>nohup</i></a>, and <a href="../utilities/xargs.html"><i>xargs</i></a> utilities in the Shell and
Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 have also been specified to use this convention.</p>

<p>When a command fails during word expansion or redirection, most historical implementations exit with a status of 1. However,
there was some sentiment that this value should probably be much higher so that an application could distinguish this case from the
more normal exit status values. Thus, the language &quot;greater than zero&quot; was selected to allow either method to be implemented.</p>

<h4><a name="tag_02_02_09"></a>Shell Commands</h4>

<p>A description of an &quot;empty command&quot; was removed from an early proposal because it is only relevant in the cases of <a href=
"../utilities/sh.html"><i>sh</i></a> <b>-c</b> <tt>""</tt> , <i>system</i>( <tt>""</tt> ), or an empty shell-script file (such as
the implementation of <a href="../utilities/true.html"><i>true</i></a> on some historical systems). Since it is no longer mentioned
in the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, it falls into the silently unspecified category of behavior
where implementations can continue to operate as they have historically, but conforming applications do not construct empty
commands. (However, note that <a href="../utilities/sh.html"><i>sh</i></a> does explicitly state an exit status for an empty string
or file.) In an interactive session or a script with other commands, extra &lt;newline&gt;s or semicolons, such as:</p>

<blockquote>
<pre>
<tt>$ false
$
$ echo $?
1
</tt>
</pre>
</blockquote>

<p>would not qualify as the empty command described here because they would be consumed by other parts of the grammar.</p>

<h5><a name="tag_02_02_09_01"></a>Simple Commands</h5>

<p>The enumerated list is used only when the command is actually going to be executed. For example, in:</p>

<blockquote>
<pre>
<tt>true || $foo *
</tt>
</pre>
</blockquote>

<p>no expansions are performed.</p>

<p>The following example illustrates both how a variable assignment without a command name affects the current execution
environment, and how an assignment with a command name only affects the execution environment of the command:</p>

<blockquote>
<pre>
<b>$</b> <tt>x=red
</tt><b>$</b> <tt>echo $x
</tt><b>red
$</b> <tt>export x
</tt><b>$</b> <tt>sh -c 'echo $x'
</tt><b>red
$</b> <tt>x=blue sh -c 'echo $x'
</tt><b>blue
$</b> <tt>echo $x
</tt><b>red</b><tt>
</tt>
</pre>
</blockquote>

<p>This next example illustrates that redirections without a command name are still performed:</p>

<blockquote>
<pre>
<b>$</b> <tt>ls foo
</tt><b>ls: foo: no such file or directory
$</b> <tt>&gt; foo
</tt><b>$</b> <tt>ls foo
</tt><b>foo</b><tt>
</tt>
</pre>
</blockquote>

<p>A command without a command name, but one that includes a command substitution, has an exit status of the last command
substitution that the shell performed. For example:</p>

<blockquote>
<pre>
<tt>if      x=$(</tt><i>command</i><tt>)
then    ...
fi
</tt>
</pre>
</blockquote>

<p>An example of redirections without a command name being performed in a subshell shows that the here-document does not disrupt
the standard input of the <b>while</b> loop:</p>

<blockquote>
<pre>
<tt>IFS=:
while    read a b
do       echo $a
         &lt;&lt;-eof
         Hello
         eof
done &lt;/etc/passwd
</tt>
</pre>
</blockquote>

<p>Following are examples of commands without command names in AND-OR lists:</p>

<blockquote>
<pre>
<tt>&gt; foo || {
    echo "error: foo cannot be created" &gt;&amp;2
    exit 1
}
<br>
# set saved if /vmunix.save exists
test -f /vmunix.save &amp;&amp; saved=1
</tt>
</pre>
</blockquote>

<p>Command substitution and redirections without command names both occur in subshells, but they are not necessarily the same ones.
For example, in:</p>

<blockquote>
<pre>
<tt>exec 3&gt; file
var=$(echo foo &gt;&amp;3) 3&gt;&amp;1
</tt>
</pre>
</blockquote>

<p>it is unspecified whether <b>foo</b> is echoed to the file or to standard output.</p>

<h5><a name="tag_02_02_09_02"></a>Command Search and Execution</h5>

<p>This description requires that the shell can execute shell scripts directly, even if the underlying system does not support the
common <tt>"#!"</tt> interpreter convention. That is, if file <b>foo</b> contains shell commands and is executable, the following
executes <b>foo</b>:</p>

<blockquote>
<pre>
<tt>./foo
</tt>
</pre>
</blockquote>

<p>The command search shown here does not match all historical implementations. A more typical sequence has been:</p>

<ul>
<li>
<p>Any built-in (special or regular)</p>
</li>

<li>
<p>Functions</p>
</li>

<li>
<p>Path search for executable files</p>