chap2.html

unix 下的C开发手册,还用详细的例程。

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

<dt><b>!</b><dd>Expands to the decimal process ID
of the most recent background command (see
<xref href=lists><a href="#tag_001_009_003">
Lists
</a></xref>)
executed from the current shell.
(For example, background commands executed from subshells
do not affect the value of
$!
in the current shell environment.)
For a pipeline, the process ID is that of the last
command in the pipeline.

<dt><b>0</b><dd>(Zero.)
Expands to the name of the shell or shell script.
See
<i><a href="sh.html">sh</a></i>
for a detailed description of how this name is derived.

</dl>
<p>
See the description of the
<i>IFS</i>
variable in
<xref href=shvars><a href="#tag_001_005_003">
Shell Variables
</a></xref>.
<p>
The descriptions of parameters "*" and "@"
assume the reader is familiar with
the field splitting discussion in
<xref href=fldspl><a href="#tag_001_006_005">
Field Splitting
</a></xref>
and understands that portions of the word will
remain concatenated unless there is some reason
to split them into separate fields.
<p>
Some examples of the "*" and "@"
properties, including the concatenation aspects:
<pre>
<code>
set "abc" "def ghi" "jkl"

echo $*        =&gt; "abc" "def" "ghi" "jkl"
echo "$*"      =&gt; "abc def ghi jkl"
echo $@        =&gt; "abc" "def" "ghi" "jkl"
</code>
</pre>
<p>
but:
<pre>
<code>
echo "$@"         =&gt; "abc" "def ghi" "jkl"
echo "xx$@yy"     =&gt; "xxabc" "def ghi" "jklyy"
echo "$@$@"       =&gt; "abc" "def ghi" "jklabc" "def ghi" "jkl"
</code>
</pre>
In the preceding examples, the double-quote
characters that appear after the
=&gt;
do not appear in the output
and are used only to illustrate word boundaries.
<h4><a name = "tag_001_005_003">&nbsp;</a>Shell Variables</h4>
<xref type="3" name="shvars"></xref>
Variables are initialised from the environment
(as defined by the <b>XSH</b> specification)
and can be given new
values with variable assignment commands.
If a variable is initialised from the environment, it is marked
for export immediately; see the
<i><a href="chap2.html#tag_001_014_008">export</a></i>
special built-in.
New variables can be defined and initialised with variable assignments,
with the
<i><a href="read.html">read</a></i>
or
<i><a href="getopts.html">getopts</a></i>
utilities, with the
<i>name</i>
parameter in a
<b>for</b>
loop,
with the
${<i>name=word</i>}
expansion or with other mechanisms
provided as implementation extensions.
The following variables affect the execution of the shell:
<dl compact>

<dt><i>ENV</i><dd>This variable, when the shell is invoked,
is subjected to parameter expansion (see
<xref href=parmexp><a href="#tag_001_006_002">
Parameter Expansion
</a></xref>)
by the shell
and the resulting value is used as a pathname of a
file containing shell commands to execute in the current environment.
The file need not be executable.
If the expanded value of
<i>ENV</i>
is not an absolute pathname, the results are unspecified.
<i>ENV</i>
will be ignored if the user's real and effective user IDs or real and
effective group IDs are different.

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 startup, whereas the
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.

<dt><i>HOME</i><dd>This variable is interpreted as the
pathname of the user's home directory.
The contents of
<i>HOME</i>
are used in tilde expansion (see
<xref href=tildexp><a href="#tag_001_006_001">
Tilde Expansion
</a></xref>).

<dt><i>IFS</i><dd><i>Input field separators</i>: a string treated as a list of characters
that is used for field splitting and to
split lines into
fields with the
<i><a href="read.html">read</a></i>
command.
If
<i>IFS</i>
is not set, the shell will behave as if the value of
<i>IFS</i>
were the
space,
tab
and
newline
characters.
(See
<xref href=fldspl><a href="#tag_001_006_005">
Field Splitting
</a></xref>.)

<dt><i>LANG</i><dd>Provide a default value for the internationalisation variables
that are unset or null.
If
<i>LANG</i>
is unset or null, the corresponding value from the
implementation-dependent default locale will be used.
If any of the internationalisation variables contains an invalid setting, the
utility will behave as if none of the variables had been defined.

<dt><i>LC_ALL</i><dd>This variable provides a default value for the
variables, as described in
the <b>XBD</b> specification, 
<a href="../xbd/envvar.html"><b>Environment Variables</b>&nbsp;</a>.

<dt><i>LC_COLLATE</i><dd>This variable determines the behaviour of range
expressions, equivalence classes and multi-character collating elements
within pattern matching.

<dt><i>LC_CTYPE</i><dd>This variable determines the
interpretation of sequences of bytes of text data
as characters (for example, single- as opposed to multi-byte
characters), which characters are defined as
letters (character class
<b>alpha</b>)
and
blank characters
(character class
<b>blank</b>),
and the behaviour of character classes within pattern matching.
Changing the value of
<i>LC_CTYPE</i>
after the shell has started does not affect
the lexical processing of shell commands in the
current shell execution environment or its subshells.
Invoking a shell script or performing
<i><a href="chap2.html#tag_001_014_006">exec</a></i>
<i><a href="sh.html">sh</a></i>
subjects the new shell to the changes in
<i>LC_CTYPE</i>.

<dt><i>LC_MESSAGES</i><dd>This variable determines
the language in which messages should be written.

<dt><i>LINENO</i><dd>This variable is set by the shell to
a decimal number representing the current
sequential line number (numbered starting with 1)
within a script or function before it executes each command.
If the user unsets or resets
<i>LINENO</i>
the variable may lose its special meaning for the life of the shell.
If the shell is not currently executing a script or function, the value of
<i>LINENO</i>
is unspecified.

<dt><i>NLSPATH</i><dd>Determine the location of message catalogues
for the processing of
<i>LC_MESSAGES</i>.

<dt><i>PATH</i><dd>This variable represents a string formatted as described in
the <b>XBD</b> specification, <b>Chapter&nbsp;6</b>, <b>Environment Variables</b>, used to effect command interpretation.
See
<xref href=cmdsea><a href="#tag_001_009_001_001">
Command Search and Execution
</a></xref>.

<dt><i>PPID</i><dd>This variable is set by the shell
to the decimal process ID of the process that invoked this shell.
In a subshell (see
<xref href=shexenv><a href="#tag_001_012">
Shell Execution Environment
</a></xref>),
<i>PPID</i>
will be set to the same
value as that of the parent of the current shell.
For example,
<i><a href="echo.html">echo</a></i>
$PPID
and
(<i>echo</i>
$PPID)
would produce the same value.

Without this variable, there is no way for a utility to signal its parent
or to find its parent process.
This is also useful to know if the shell has been orphaned.

<dt><i>PS1</i><dd>Each time an interactive shell is ready to read a command,
the value of this variable
is subjected to parameter expansion
and written to standard error.
The default value is
"$ ".
For users who have specific
additional implementation-dependent privileges,
the default may be another, implementation-dependent, value.
(Historically, the superuser has had a prompt of
"# ".)
The shell replaces each instance of the character
"!"
in
<i>PS1</i>
with the history file number of the next command to be typed.
Escaping the
"!"
with another
"!"
(that is,
!!)
places the literal character
"!"
in the prompt.

<dt><i>PS2</i><dd>Each time the user enters a
newline character
prior to completing a command line in
an interactive shell,
the value of this variable
is subjected to parameter expansion
and written to standard error.
The default value is
"&gt; ".

<dt><i>PS4</i><dd>When an execution trace
(<i>set</i>
<b>-x</b>)
is being performed in an interactive shell,
before each line in the execution trace,
the value of this variable
is subjected to parameter expansion
and written to standard error.
The default value is
"+ ".

For example, the following script:
<pre>
<code>
PS4='[${LINENO}]+ '
set -x
echo Hello
</code>
</pre>
writes the following to standard error:
<pre>
<code>
[3]+ echo Hello
</code>
</pre>

</dl>
<p>
Tilde expansion for components of the
in an assignment such as:
<pre>
<code>
PATH=~hlj/bin:~dwc/bin:$PATH
</code>
</pre>
is a feature of
some historical shells and is allowed by the wording of
<xref href=tildexp><a href="#tag_001_006_001">
Tilde Expansion
</a></xref>.
Note that the tildes are expanded during the assignment to
<i>PATH</i>
not when
<i>PATH</i>
is accessed during command search.
<hr size=2 noshade>
<h3><a name = "tag_001_006">&nbsp;</a>Word Expansions</h3>
<xref type="2" name="wordexp"></xref>
This section describes the various expansions that are performed on words.
Not all expansions are performed on every word, as explained
in the following sections.
<p>
Tilde expansions, parameter expansions,
command substitutions, arithmetic expansions
and quote removals that occur within a single word
expand to a single field.
It is only field splitting
or pathname expansion that can create multiple fields
from a single word.
The single exception to this rule
is the expansion of the special parameter "@" within
double-quotes, as described in
<xref href=specpar><a href="#tag_001_005_002">
Special Parameters
</a></xref>.
<p>
The order of word expansion is as follows:
<ol>
<p>
<li>
Tilde expansion (see
<xref href=tildexp><a href="#tag_001_006_001">
Tilde Expansion
</a></xref>),
parameter expansion (see
<xref href=parmexp><a href="#tag_001_006_002">
Parameter Expansion
</a></xref>),
command substitution (see
<xref href=cmdsub><a href="#tag_001_006_003">
Command Substitution
</a></xref>),
and arithmetic expansion (see
<xref href=aritexp><a href="#tag_001_006_004">
Arithmetic Expansion
</a></xref>)
are performed, beginning to end.
See item 5 in
<xref href=token><a href="#tag_001_003">
Token Recognition
</a></xref>.
<p>
<li>
Field splitting (see
<xref href=fldspl><a href="#tag_001_006_005">
Field Splitting
</a></xref>)
is performed on the portions of the fields generated by step 1, unless
is null.
<p>
<li>
Pathname expansion (see
<xref href=pathexp><a href="#tag_001_006_006">
Pathname Expansion
</a></xref>)
is performed, unless
<i>set</i>
<b>-f</b>
is in effect.
<p>
<li>
Quote removal (see
<xref href=quoterm><a href="#tag_001_006_007">
Quote Removal
</a></xref>)
always is performed last.
<p>
</ol>
<p>
The expansions described in this section
will occur in the same shell environment
as that in which the command is executed.
<p>
If the complete expansion appropriate for a word results
in an empty field, that empty field will be deleted from
the list of fields that form the completely expanded
command, unless the original word contained
single-quote or double-quote characters.
<p>
The "$" character is used to introduce
parameter expansion, command substitution
or arithmetic evaluation.
If an unquoted "$" is followed by a character that is
either not numeric,
the name of one of the special parameters (see
<xref href=specpar><a href="#tag_001_005_002">
Special Parameters
</a></xref>),
a valid first character of a variable name,
a left curly brace
({)
or a left parenthesis,
the result is unspecified.
<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 behaviour.
All useful applications of
<i>IFS</i>
use it for parsing input of the
<i><a href="read.html">read</a></i>
utility and for splitting the results
of parameter and command substitution.
<p>
The rule concerning expansion to a single field
requires that if
<b>foo=abc</b>
and
<b>bar=def</b>,
that:
<pre>
<code>
"$foo""$bar"
</code>
</pre>
expands to the single field:
<pre>
<code>
abcdef
</code>
</pre>
<p>
The rule concerning empty fields can be illustrated by:
<pre>
<code>
<b>$</b>    unset foo
<b>$</b>    set $foo bar '' xyz "$foo" abc
<b>$</b>    for i
<b>&gt;</b>    do
<b>&gt;</b>        echo "-$i-"
<b>&gt;</b>    done
<b>-bar-
--
-xyz-
--
-abc-</b>
</code>
</pre>
<p>
Step 2 indicates that parameter expansion, command substitution
and arithmetic expansion are all processed simultaneously
as they are scanned.
For example, the following is valid arithmetic: