xcu_chap02.html

posix标准英文,html格式

    echo "error: foo cannot be created" >&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>
</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>

<p>IEEE&nbsp;Std&nbsp;1003.1-2001/Cor&nbsp;2-2004, item XCU/TC2/D6/4 is applied, updating the case where <a href=
"../functions/execve.html"><i>execve</i>()</a> fails due to an error equivalent to the [ENOEXEC] error.</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.<br>
</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>