xcu_chap02.html

IEEE 1003.1-2003, Single Unix Specification v3

</li>
</ul>

<p>But there are problems with this sequence. Since the programmer has no idea in advance which utilities might have been built
into the shell, a function cannot be used to override portably a utility of the same name. (For example, a function named <a href=
"../utilities/cd.html"><i>cd</i></a> cannot be written for many historical systems.) Furthermore, the <i>PATH</i> variable is
partially ineffective in this case, and only a pathname with a slash can be used to ensure a specific executable file is
invoked.</p>

<p>After the <a href="../functions/execve.html"><i>execve</i>()</a> failure described, the shell normally executes the file as a
shell script. Some implementations, however, attempt to detect whether the file is actually a script and not an executable from
some other architecture. The method used by the KornShell is allowed by the text that indicates non-text files may be bypassed.</p>

<p>The sequence selected for the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 acknowledges that special built-ins
cannot be overridden, but gives the programmer full control over which versions of other utilities are executed. It provides a
means of suppressing function lookup (via the <a href="../utilities/command.html"><i>command</i></a> utility) for the user's own
functions and ensures that any regular built-ins or functions provided by the implementation are under the control of the path
search. The mechanisms for associating built-ins or functions with executable files in the path are not specified by the Shell and
Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, but the wording requires that if either is implemented, the application is not
able to distinguish a function or built-in from an executable (other than in terms of performance, presumably). The implementation
ensures that all effects specified by the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 resulting from the
invocation of the regular built-in or function (interaction with the environment, variables, traps, and so on) are identical to
those resulting from the invocation of an executable file.</p>

<h5><a name="tag_02_02_09_03"></a>Examples</h5>

<p>Consider three versions of the <a href="../utilities/ls.html"><i>ls</i></a> utility:</p>

<ol>
<li>
<p>The application includes a shell function named <a href="../utilities/ls.html"><i>ls</i></a>.</p>
</li>

<li>
<p>The user writes a utility named <a href="../utilities/ls.html"><i>ls</i></a> and puts it in <b>/fred/bin</b>.</p>
</li>

<li>
<p>The example implementation provides <a href="../utilities/ls.html"><i>ls</i></a> as a regular shell built-in that is invoked
(either by the shell or directly by <i>exec</i>) when the path search reaches the directory <b>/posix/bin</b>.</p>
</li>
</ol>

<p>If <i>PATH =</i> <b>/posix/bin</b>, various invocations yield different versions of <a href=
"../utilities/ls.html"><i>ls</i></a>:</p>

<center>
<table border="1" cellpadding="3" align="center">
<tr valign="top">
<th align="center">
<p class="tent"><b>Invocation</b></p>
</th>
<th align="center">
<p class="tent"><b>Version of <i>ls</i></b></p>
</th>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><i>ls</i> (from within application script)</p>
</td>
<td align="left">
<p class="tent">(1) function</p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><i>command ls</i> (from within application script)</p>
</td>
<td align="left">
<p class="tent">(3) built-in</p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><i>ls</i> (from within makefile called by application)</p>
</td>
<td align="left">
<p class="tent">(3) built-in</p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><i>system</i>("<i>ls</i>")</p>
</td>
<td align="left">
<p class="tent">(3) built-in</p>
</td>
</tr>

<tr valign="top">
<td align="left">
<p class="tent"><i>PATH</i>="<b>/fred/bin</b>:$<i>PATH</i>" <i>ls</i></p>
</td>
<td align="left">
<p class="tent">(2) user's version</p>
</td>
</tr>
</table>
</center>

<h5><a name="tag_02_02_09_04"></a>Pipelines</h5>

<p>Because pipeline assignment of standard input or standard output or both takes place before redirection, it can be modified by
redirection. For example:</p>

<blockquote>
<pre>
<b>$</b> <i>command1</i> <tt>2&gt;&amp;1 |</tt> <i>command2</i>
</pre>
</blockquote>

<p>sends both the standard output and standard error of <i>command1</i> to the standard input of <i>command2</i>.</p>

<p>The reserved word <b>!</b> allows more flexible testing using AND and OR lists.</p>

<p>It was suggested that it would be better to return a non-zero value if any command in the pipeline terminates with non-zero
status (perhaps the bitwise-inclusive OR of all return values). However, the choice of the last-specified command semantics are
historical practice and would cause applications to break if changed. An example of historical behavior:</p>

<blockquote>
<pre>
<tt>$ sleep 5 | (exit 4)
$ echo $?
4
$ (exit 4) | sleep 5
$ echo $?
0
</tt>
</pre>
</blockquote>

<h5><a name="tag_02_02_09_05"></a>Lists</h5>

<p>The equal precedence of <tt>"&amp;&amp;"</tt> and <tt>"||"</tt> is historical practice. The standard developers evaluated the
model used more frequently in high-level programming languages, such as C, to allow the shell logical operators to be used for
complex expressions in an unambiguous way, but they could not allow historical scripts to break in the subtle way unequal
precedence might cause. Some arguments were posed concerning the <tt>"{}"</tt> or <tt>"()"</tt> groupings that are required
historically. There are some disadvantages to these groupings:</p>

<ul>
<li>
<p>The <tt>"()"</tt> can be expensive, as they spawn other processes on some implementations. This performance concern is primarily
an implementation issue.</p>
</li>

<li>
<p>The <tt>"{}"</tt> braces are not operators (they are reserved words) and require a trailing space after each <tt>'{'</tt> , and
a semicolon before each <tt>'}'</tt> . Most programmers (and certainly interactive users) have avoided braces as grouping
constructs because of the problematic syntax required. Braces were not changed to operators because that would generate
compatibility issues even greater than the precedence question; braces appear outside the context of a keyword in many shell
scripts.</p>
</li>
</ul>

<p>IEEE PASC Interpretation 1003.2 #204 is applied, clarifying that the operators <tt>"&amp;&amp;"</tt> and <tt>"||"</tt> are
evaluated with left associativity.</p>

<h5><a name="tag_02_02_09_06"></a>Asynchronous Lists</h5>

<p>The grammar treats a construct such as:</p>

<blockquote>
<pre>
<tt>foo &amp; bar &amp; bam &amp;
</tt>
</pre>
</blockquote>

<p>as one &quot;asynchronous list&quot;, but since the status of each element is tracked by the shell, the term &quot;element of an
asynchronous list&quot; was introduced to identify just one of the <b>foo</b>, <b>bar</b>, or <b>bam</b> portions of the overall
list.</p>

<p>Unless the implementation has an internal limit, such as {CHILD_MAX}, on the retained process IDs, it would require unbounded
memory for the following example:</p>

<blockquote>
<pre>
<tt>while true
do      foo &amp; echo $!
done
</tt>
</pre>
</blockquote>

<p>The treatment of the signals SIGINT and SIGQUIT with asynchronous lists is described in the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../utilities/xcu_chap02.html#tag_02_11">Section 2.11, Signals and Error Handling</a>.</p>

<p>Since the connection of the input to the equivalent of <b>/dev/null</b> is considered to occur before redirections, the
following script would produce no output:</p>

<blockquote>
<pre>
<tt>exec &lt; /etc/passwd
cat &lt;&amp;0 &amp;
wait
</tt>
</pre>
</blockquote>

<h5><a name="tag_02_02_09_07"></a>Sequential Lists</h5>

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

<h5><a name="tag_02_02_09_08"></a>AND Lists</h5>

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

<h5><a name="tag_02_02_09_09"></a>OR Lists</h5>

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

<h5><a name="tag_02_02_09_10"></a>Compound Commands</h5>

<h5><a name="tag_02_02_09_11"></a>Grouping Commands</h5>

<p>The semicolon shown in { <i>compound-list</i>;} is an example of a control operator delimiting the <b>}</b> reserved word. Other
delimiters are possible, as shown in the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../utilities/xcu_chap02.html#tag_02_10">Section 2.10, Shell Grammar</a>; &lt;newline&gt; is frequently used.</p>

<p>A proposal was made to use the <b>&lt;do-done&gt;</b> construct in all cases where command grouping in the current process
environment is performed, identifying it as a construct for the grouping commands, as well as for shell functions. This was not
included because the shell already has a grouping construct for this purpose ( <tt>"{}"</tt> ), and changing it would have been
counter-productive.</p>

<h5><a name="tag_02_02_09_12"></a>For Loop</h5>

<p>The format is shown with generous usage of &lt;newline&gt;s. See the grammar in the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../utilities/xcu_chap02.html#tag_02_10">Section 2.10, Shell Grammar</a> for a precise
description of where &lt;newline&gt;s and semicolons can be interchanged.</p>

<p>Some historical implementations support <tt>'{'</tt> and <tt>'}'</tt> as substitutes for <b>do</b> and <b>done</b>. The standard
developers chose to omit them, even as an obsolescent feature. (Note that these substitutes were only for the <b>for</b> command;
the <b>while</b> and <b>until</b> commands could not use them historically because they are followed by compound-lists that may
contain <tt>"{...}"</tt> grouping commands themselves.)</p>

<p>The reserved word pair <b>do</b> ... <b>done</b> was selected rather than <b>do</b> ... <b>od</b> (which would have matched the
spirit of <b>if</b> ... <b>fi</b> and <b>case</b> ... <b>esac</b>) because <a href="../utilities/od.html"><i>od</i></a> is already
the name of a standard utility.</p>

<p>PASC Interpretation 1003.2 #169 has been applied changing the grammar.</p>

<h5><a name="tag_02_02_09_13"></a>Case Conditional Construct</h5>

<p>An optional left parenthesis before <i>pattern</i> was added to allow numerous historical KornShell scripts to conform. At one
time, using the leading parenthesis was required if the <b>case</b> statement was to be embedded within a <tt>"$()"</tt> command
substitution; this is no longer the case with the POSIX shell. Nevertheless, many historical scripts use the left parenthesis, if
only because it makes matching-parenthesis searching easier in <a href="../utilities/vi.html"><i>vi</i></a> and other editors. This
is a relatively simple implementation change that is upwards-compatible for all scripts.</p>

<p>Consideration was given to requiring <a href="../utilities/break.html"><i>break</i></a> inside the
<i>compound-list</i> to prevent falling through to the next pattern action list. This was rejected as being nonexisting practice.
An interesting undocumented feature of the KornShell is that using <tt>";&amp;"</tt> instead of <tt>";;"</tt> as a terminator
causes the exact opposite behavior-the flow of control continues with the next <i>compound-list</i>.</p>

<p>The pattern <tt>'*'</tt> , given as the last pattern in a <b>case</b> construct, is equivalent to the default case in a
C-language <b>switch</b> statement.</p>

<p>The grammar shows that reserved words can be used as patterns, even if one is the first word on a line. Obviously, the reserved
word <b>esac</b> cannot be used in this manner.</p>

<h5><a name="tag_02_02_09_14"></a>If Conditional Construct</h5>

<p>The precise format for the command syntax is described in the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a
href="../utilities/xcu_chap02.html#tag_02_10">Section 2.10, Shell Grammar</a>.</p>

<h5><a name="tag_02_02_09_15"></a>While Loop</h5>

<p>The precise format for the command syntax is described in the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a
href="../utilities/xcu_chap02.html#tag_02_10">Section 2.10, Shell Grammar</a>.</p>

<h5><a name="tag_02_02_09_16"></a>Until Loop</h5>

<p>The precise format for the command syntax is described in the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a
href="../utilities/xcu_chap02.html#tag_02_10">Section 2.10, Shell Grammar</a>.</p>

<h5><a name="tag_02_02_09_17"></a>Function Definition Command</h5>

<p>The description of functions in an early proposal was based on the notion that functions should behave like miniature shell
scripts; that is, except for sharing variables, most elements of an execution environment should behave as if they were a new
execution environment, and changes to these should be local to the function. For example, traps and options should be reset on
entry to the function, and any changes to them do not affect the traps or options of the caller. There were numerous objections to
this basic idea, and the opponents asserted that functions were intended to be a convenient mechanism for grouping common commands
that were to be executed in the current execution environment, similar to the execution of the <a href=
"../utilities/dot.html"><i>dot</i></a> special built-in.</p>

<p>It was also pointed out that the functions described in that early proposal did not provide a local scope for everything a new
shell script would, such as the current working directory, or <a href="../utilities/umask.html"><i>umask</i></a>, but instead
provided a local scope for only a few select properties. The basic argument was that if a local scope is needed for the execution
environment, the mechanism already existed: the application can put the commands in a new shell script and call that script. All
historical shells that implemented functions, other than the KornShell, have implemented functions that operate in the current
execution environment. Because of this, traps and options have a global scope within a shell script. Local variables within a
function were considered and included in another early proposal (controlled by the special built-in <i>local</i>), but were removed
because they do not fit the simple model developed for functions and because there was some opposition to adding yet another new
special built-in that was not part of historical practice. Implementations should reserve the identifier <i>local</i> (as well as
<i>typeset</i>, as used in the KornShell) in case this local variable mechanism is adopted in a future version of
IEEE&nbsp;Std&nbsp;1003.1-2001.</p>

<p>A separate issue from the execution environment of a function is the availability of that function to child shells. A few
objectors maintained that just as a