xcu_chap02.html

IEEE 1003.1-2003, Single Unix Specification v3

<h5><a name="tag_02_02_05_01"></a>Positional Parameters</h5>

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

<h5><a name="tag_02_02_05_02"></a>Special Parameters</h5>

<p>Most historical implementations implement subshells by forking; thus, the special parameter <tt>'$'</tt> does not necessarily
represent the process ID of the shell process executing the commands since the subshell execution environment preserves the value
of <tt>'$'</tt> .</p>

<p>If a subshell were to execute a background command, the value of <tt>"$!"</tt> for the parent would not change. For example:</p>

<blockquote>
<pre>
<tt>(
date &amp;
echo $!
)
echo $!
</tt>
</pre>
</blockquote>

<p>would echo two different values for <tt>"$!"</tt> .</p>

<p>The <tt>"$-"</tt> special parameter can be used to save and restore <a href="../utilities/set.html"><i>set</i></a>
options:</p>

<blockquote>
<pre>
<tt>Save=$(echo $- | sed 's/[ics]//g')
...
set +aCefnuvx
if [ -n "$Save" ]; then
    set -$Save
fi
</tt>
</pre>
</blockquote>

<p>The three options are removed using <a href="../utilities/sed.html"><i>sed</i></a> in the example because they may appear in the
value of <tt>"$-"</tt> (from the <a href="../utilities/sh.html"><i>sh</i></a> command line), but are not valid options to <a href=
"../utilities/set.html"><i>set</i></a>.</p>

<p>The descriptions of parameters <tt>'*'</tt> and <tt>'@'</tt> assume the reader is familiar with the field splitting discussion
in the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../utilities/xcu_chap02.html#tag_02_06_05">Section
2.6.5, Field Splitting</a> and understands that portions of the word remain concatenated unless there is some reason to split them
into separate fields.</p>

<p>Some examples of the <tt>'*'</tt> and <tt>'@'</tt> properties, including the concatenation aspects:</p>

<blockquote>
<pre>
<tt>set "abc" "def ghi" "jkl"
<br>
echo $*    =&gt; "abc" "def" "ghi" "jkl"
echo "$*"  =&gt; "abc def ghi jkl"
echo $@    =&gt; "abc" "def" "ghi" "jkl"
</tt>
</pre>
</blockquote>

<p>but:</p>

<blockquote>
<pre>
<tt>echo "$@"      =&gt; "abc" "def ghi" "jkl"
echo "xx$@yy"  =&gt; "xxabc" "def ghi" "jklyy"
echo "$@$@"    =&gt; "abc" "def ghi" "jklabc" "def ghi" "jkl"
</tt>
</pre>
</blockquote>

<p>In the preceding examples, the double-quote characters that appear after the <tt>"=&gt;"</tt> do not appear in the output and
are used only to illustrate word boundaries.</p>

<p>The following example illustrates the effect of setting <i>IFS</i> to a null string:</p>

<blockquote>
<pre>
<b>$</b> <tt>IFS=''
</tt><b>$</b> <tt>set foo bar bam
</tt><b>$</b> <tt>echo "$@"
</tt><b>foo bar bam</b><tt>
</tt><b>$</b> <tt>echo "$*"
</tt><b>foobarbam</b><tt>
</tt><b>$</b> <tt>unset IFS
</tt><b>$</b> <tt>echo "$*"
</tt><b>foo bar bam</b><tt>
</tt>
</pre>
</blockquote>

<h5><a name="tag_02_02_05_03"></a>Shell Variables</h5>

<p>See the discussion of <i>IFS</i> in <a href="#tag_02_02_06_05">Field Splitting</a> and the RATIONALE for the <a href=
"../utilities/sh.html"><i>sh</i></a> utility.</p>

<p>The prohibition on <i>LC_CTYPE</i> changes affecting lexical processing protects the shell implementor (and the shell
programmer) from the ill effects of changing the definition of &lt;blank&gt; or the set of alphabetic characters in the current
environment. It would probably not be feasible to write a compiled version of a shell script without this rule. The rule applies
only to the current invocation of the shell and its subshells-invoking a shell script or performing <a href=
"../utilities/exec.html"><i>exec</i></a> <a href="../utilities/sh.html"><i>sh</i></a> would subject the new shell to the
changes in <i>LC_CTYPE .</i></p>

<p>Other common environment variables used by historical shells are not specified by the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, but they should be reserved for the historical uses.</p>

<p>Tilde expansion for components of <i>PATH</i> in an assignment such as:</p>

<blockquote>
<pre>
<tt>PATH=&#152;hlj/bin:&#152;dwc/bin:$PATH
</tt>
</pre>
</blockquote>

<p>is a feature of some historical shells and is allowed by the wording of the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../utilities/xcu_chap02.html#tag_02_06_01">Section 2.6.1, Tilde Expansion</a>. Note that
the tildes are expanded during the assignment to <i>PATH ,</i> not when <i>PATH</i> is accessed during command search.</p>

<p>The following entries represent additional information about variables included in the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, or rationale for common variables in use by shells that have been excluded:</p>

<dl compact>
<dt><tt>_</tt></dt>

<dd>(Underscore.) While underscore is historical practice, its overloaded usage in the KornShell is confusing, and it has been
omitted from the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001.</dd>

<dt><i>ENV</i></dt>

<dd>This variable can be used to set aliases and other items local to the invocation of a shell. The file referred to by <i>ENV</i>
differs from <b>$HOME/.profile</b> in that <b>.profile</b> is typically executed at session start-up, whereas the <i>ENV</i> file
is executed at the beginning of each shell invocation. The <i>ENV</i> value is interpreted in a manner similar to a dot script, in
that the commands are executed in the current environment and the file needs to be readable, but not executable. However, unlike
dot scripts, no <i>PATH</i> searching is performed. This is used as a guard against Trojan Horse security breaches.</dd>

<dt><i>ERRNO</i></dt>

<dd>This variable was omitted from the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001 because the values of error
numbers are not defined in IEEE&nbsp;Std&nbsp;1003.1-2001 in a portable manner.</dd>

<dt><i>FCEDIT</i></dt>

<dd>Since this variable affects only the <a href="../utilities/fc.html"><i>fc</i></a> utility, it has been omitted from this more
global place. The value of <i>FCEDIT</i> does not affect the command-line editing mode in the shell; see the description of <a
href="../utilities/set.html"><i>set</i></a> <b>-o</b> <i>vi</i> in the <a href=
"../utilities/set.html"><i>set</i></a> built-in utility.</dd>

<dt><i>PS1</i></dt>

<dd>This variable is used for interactive prompts. Historically, the &quot;superuser&quot; has had a prompt of <tt>'#'</tt> . Since
privileges are not required to be monolithic, it is difficult to define which privileges should cause the alternate prompt.
However, a sufficiently powerful user should be reminded of that power by having an alternate prompt.</dd>

<dt><i>PS3</i></dt>

<dd>This variable is used by the KornShell for the <i>select</i> command. Since the POSIX shell does not include <i>select</i>,
<i>PS3</i> was omitted.</dd>

<dt><i>PS4</i></dt>

<dd>This variable is used for shell debugging. For example, the following script: 

<blockquote>
<pre>
<tt>PS4='[${LINENO}]+ '
set -x
echo Hello
</tt>
</pre>
</blockquote>

<p>writes the following to standard error:</p>

<blockquote>
<pre>
<tt>[3]+ echo Hello
</tt>
</pre>
</blockquote>
</dd>

<dt><i>RANDOM</i></dt>

<dd>This pseudo-random number generator was not seen as being useful to interactive users.</dd>

<dt><i>SECONDS</i></dt>

<dd>Although this variable is sometimes used with <i>PS1</i> to allow the display of the current time in the prompt of the user, it
is not one that would be manipulated frequently enough by an interactive user to include in the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001.</dd>
</dl>

<h4><a name="tag_02_02_06"></a>Word Expansions</h4>

<p>Step (2) refers to the &quot;portions of fields generated by step (1)&quot;. For example, if the word being expanded were
<tt>"$x+$y"</tt> and <i>IFS =+,</i> the word would be split only if <tt>"$x"</tt> or <tt>"$y"</tt> contained <tt>'+'</tt> ; the
<tt>'+'</tt> in the original word was not generated by step (1).</p>

<p><i>IFS</i> is used for performing field splitting on the results of parameter and command substitution; it is not used for
splitting all fields. Previous versions of the shell used it for splitting all fields during field splitting, but this has severe
problems because the shell can no longer parse its own script. There are also important security implications caused by this
behavior. All useful applications of <i>IFS</i> use it for parsing input of the <a href="../utilities/read.html"><i>read</i></a>
utility and for splitting the results of parameter and command substitution.</p>

<p>The rule concerning expansion to a single field requires that if <b>foo</b>= <b>abc</b> and <b>bar</b>= <b>def</b>, that:</p>

<blockquote>
<pre>
<tt>"$foo""$bar"
</tt>
</pre>
</blockquote>

<br>
<p>expands to the single field:</p>

<blockquote>
<pre>
<tt>abcdef
</tt>
</pre>
</blockquote>

<p>The rule concerning empty fields can be illustrated by:</p>

<blockquote>
<pre>
<b>$</b> <tt>   unset foo
</tt><b>$</b> <tt>   set $foo bar &quot; xyz "$foo" abc
</tt><b>$</b> <tt>   for i
</tt><b>&gt;</b> <tt>   do
</tt><b>&gt;</b> <tt>       echo "-$i-"
</tt><b>&gt;</b> <tt>   done
</tt><b>-bar-
--
-xyz-
--
-abc-</b>
</pre>
</blockquote>

<p>Step (1) indicates that parameter expansion, command substitution, and arithmetic expansion are all processed simultaneously as
they are scanned. For example, the following is valid arithmetic:</p>

<blockquote>
<pre>
<tt>x=1
echo $(( $(echo 3)+$x ))
</tt>
</pre>
</blockquote>

<p>An early proposal stated that tilde expansion preceded the other steps, but this is not the case in known historical
implementations; if it were, and if a referenced home directory contained a <tt>'$'</tt> character, expansions would result within
the directory name.</p>

<h5><a name="tag_02_02_06_01"></a>Tilde Expansion</h5>

<p>Tilde expansion generally occurs only at the beginning of words, but an exception based on historical practice has been
included:</p>

<blockquote>
<pre>
<tt>PATH=/posix/bin:&#152;dgk/bin
</tt>
</pre>
</blockquote>

<p>This is eligible for tilde expansion because tilde follows a colon and none of the relevant characters is quoted. Consideration
was given to prohibiting this behavior because any of the following are reasonable substitutes:</p>

<blockquote>
<pre>
<tt>PATH=$(printf %s &#152;karels/bin : &#152;bostic/bin)
<br>
for Dir in &#152;maart/bin &#152;srb/bin ...
do
    PATH=${PATH:+$PATH:}$Dir
done
</tt>
</pre>
</blockquote>

<p>In the first command, explicit colons are used for each directory. In all cases, the shell performs tilde expansion on each
directory because all are separate words to the shell.</p>

<p>Note that expressions in operands such as:</p>

<blockquote>
<pre>
<tt>make -k mumble LIBDIR=&#152;chet/lib
</tt>
</pre>
</blockquote>

<p>do not qualify as shell variable assignments, and tilde expansion is not performed (unless the command does so itself, which <a
href="../utilities/make.html"><i>make</i></a> does not).</p>

<p>Because of the requirement that the word is not quoted, the following are not equivalent; only the last causes tilde
expansion:</p>

<blockquote>
<pre>