The Open Group Base Specifications Issue 8 IEEE Std 1003.1-2024 Copyright © 2001-2024 The IEEE and The Open Group

---

This chapter contains the definition of the Shell Command Language.

2.1 Shell Introduction

The shell is a command language interpreter. This chapter describes the syntax of that command language as it is used by the sh utility and the system() and popen() functions defined in the System Interfaces volume of POSIX.1-2024.

The shell operates according to the following general overview of operations. The specific details are included in the cited sections of this chapter.

The shell reads its input from a file (see sh), from the -c option or from the system() and popen() functions defined in the System Interfaces volume of POSIX.1-2024. If the first line of a file of shell commands starts with the characters "#!", the results are unspecified. 1.

The shell breaks the input into tokens: words and operators; see 2.3 Token Recognition. 1.

The shell parses the input into simple commands (see 2.9.1 Simple Commands) and compound commands (see 2.9.4 Compound Commands). 1.

For each word within a command, the shell processes <backslash>-escape sequences inside dollar-single-quotes (see 2.2.4 Dollar-Single-Quotes) and then performs various word expansions (see 2.6 Word Expansions). In the case of a simple command, the results usually include a list of pathnames and fields to be treated as a command name and arguments; see 2.9 Shell Commands. 1.

The shell performs redirection (see 2.7 Redirection) and removes redirection operators and their operands from the parameter list. 1.

The shell executes a function (see 2.9.5 Function Definition Command), built-in (see 2.15 Special Built-In Utilities), executable file, or script, giving the names of the arguments as positional parameters numbered 1 to n, and the name of the command (or in the case of a function within a script, the name of the script) as special parameter 0 (see 2.9.1.4 Command Search and Execution). 1.

The shell optionally waits for the command to complete and collects the exit status (see 2.8.2 Exit Status for Commands).

2.2 Quoting

Quoting is used to remove the special meaning of certain characters or words to the shell. Quoting can be used to preserve the literal meaning of the special characters in the next paragraph, prevent reserved words from being recognized as such, and prevent parameter expansion and command substitution within here-document processing (see 2.7.4 Here-Document ).

The application shall quote the following characters if they are to represent themselves:

|  &  ;  <  >  (  )  $  `  \  "  '  <space>  <tab>  <newline>

and the following might need to be quoted under certain circumstances. That is, these characters are sometimes special depending on conditions described elsewhere in this volume of POSIX.1-2024:

*  ?  [  ]  ^  -  !  #  ~  =  %  {  ,  }

Note: A future version of this standard may extend the conditions under which these characters are special. Therefore applications should quote them whenever they are intended to represent themselves. This does not apply to <hyphen-minus> (‘-’) since it is in the portable filename character set.

The various quoting mechanisms are the escape character, single-quotes, double-quotes, and dollar-single-quotes. The here-document represents another form of quoting; see 2.7.4 Here-Document.

2.2.1 Escape Character (Backslash)

A <backslash> that is not quoted shall preserve the literal value of the following character, with the exception of a <newline>. If a <newline> immediately follows the <backslash>, the shell shall interpret this as line continuation. The <backslash> and <newline> shall be removed before splitting the input into tokens. Since the escaped <newline> is removed entirely from the input and is not replaced by any white space, it cannot serve as a token separator.

2.2.2 Single-Quotes

Enclosing characters in single-quotes (‘’) shall preserve the literal value of each character within the single-quotes. A single-quote cannot occur within single-quotes.

2.2.3 Double-Quotes

Enclosing characters in double-quotes ("") shall preserve the literal value of all characters within the double-quotes, with the exception of the characters backquote, <dollar-sign>, and <backslash>, as follows:

$ The <dollar-sign> shall retain its special meaning introducing parameter expansion (see 2.6.2 Parameter Expansion), a form of command substitution (see 2.6.3 Command Substitution), and arithmetic expansion (see 2.6.4 Arithmetic Expansion), but shall not retain its special meaning introducing the dollar-single-quotes form of quoting (see 2.2.4 Dollar-Single-Quotes).

The input characters within the quoted string that are also enclosed between "$(" and the matching ‘)’ shall not be affected by the double-quotes, but rather shall define the command(s) whose output replaces the "$(...)" when the word is expanded. The tokenizing rules in 2.3 Token Recognition shall be applied recursively to find the matching ‘)’.

For the four varieties of parameter expansion that provide for substring processing (see 2.6.2 Parameter Expansion), within the string of characters from an enclosed "${" to the matching ‘}’, the double-quotes within which the expansion occurs shall have no effect on the handling of any special characters.

For parameter expansions other than the four varieties that provide for substring processing, within the string of characters from an enclosed "${" to the matching ‘}’, the double-quotes within which the expansion occurs shall preserve the literal value of all characters, with the exception of the characters double-quote, backquote, <dollar-sign>, and <backslash>. If any unescaped double-quote characters occur within the string, other than in embedded command substitutions, the behavior is unspecified. The backquote and <dollar-sign> characters shall follow the same rules as for characters in double-quotes described in this section. The <backslash> character shall follow the same rules as for characters in double-quotes described in this section except that it shall additionally retain its special meaning as an escape character when followed by ‘}’ and this shall prevent the escaped ‘}’ from being considered when determining the matching ‘}’ (using the rule in 2.6.2 Parameter Expansion).

` The backquote shall retain its special meaning introducing the other form of command substitution (see 2.6.3 Command Substitution). The portion of the quoted string from the initial backquote and the characters up to the next backquote that is not preceded by a <backslash>, having escape characters removed, defines that command whose output replaces "`...`" when the word is expanded. Either of the following cases produces undefined results:

A quoted (single-quoted, double-quoted, or dollar-single-quoted) string that begins, but does not end, within the "`...`" sequence

A "`...`" sequence that begins, but does not end, within the same double-quoted string \ Outside of "$(...)" and "${...}" the <backslash> shall retain its special meaning as an escape character (see 2.2.1 Escape Character (Backslash)) only when immediately followed by one of the following characters:

$   `   \   <newline>

or by a double-quote character that would otherwise be considered special (see 2.6.4 Arithmetic Expansion and 2.7.4 Here-Document).

When double-quotes are used to quote a parameter expansion, command substitution, or arithmetic expansion, the literal value of all characters within the result of the expansion shall be preserved.

The application shall ensure that a double-quote that is not within "$(...)" nor within "${...}" is immediately preceded by a <backslash> in order to be included within double-quotes. The parameter ‘@’ has special meaning inside double-quotes and is described in 2.5.2 Special Parameters.

2.2.4 Dollar-Single-Quotes

A sequence of characters starting with a <dollar-sign> immediately followed by a single-quote ($‘) shall preserve the literal value of all characters up to an unescaped terminating single-quote (’), with the exception of certain <backslash>-escape sequences, as follows:

" yields a <quotation-mark> (double-quote) character, but note that <quotation-mark> can be included unescaped.

' yields an <apostrophe> (single-quote) character.

\ yields a <backslash> character.

\a yields an <alert> character.

\b yields a <backspace> character.

\e yields an <ESC> character.

\f yields a <form-feed> character.

\n yields a <newline> character.

\r yields a <carriage-return> character.

\t yields a <tab> character.

\v yields a <vertical-tab> character.

\cX yields the control character listed in the Value column of Values for cpio c_mode Field in the OPERANDS section of the stty utility when X is one of the characters listed in the ^c column of the same table, except that \c\ yields the <FS> control character since the <backslash> character has to be escaped.

\xXX yields the byte whose value is the hexadecimal value XX (one or more hexadecimal digits). If more than two hexadecimal digits follow \x, the results are unspecified.

*ddd* yields the byte whose value is the octal value ddd (one to three octal digits).

The behavior of an unescaped <backslash> immediately followed by any other character, including <newline>, is unspecified.

In cases where a variable number of characters can be used to specify an escape sequence (\xXX and *ddd*), the escape sequence shall be terminated by the first character that is not of the expected type or, for *ddd* sequences, when the maximum number of characters specified has been found, whichever occurs first.

These <backslash>-escape sequences shall be processed (replaced with the bytes or characters they yield) immediately prior to word expansion (see 2.6 Word Expansions) of the word in which the dollar-single-quotes sequence occurs.

If a \xXX or *ddd* escape sequence yields a byte whose value is 0, it is unspecified whether that null byte is included in the result or if that byte and any following regular characters and escape sequences up to the terminating unescaped single-quote are evaluated and discarded.

If the octal value specified by *ddd* will not fit in a byte, the results are unspecified.

If a \e or \cX escape sequence specifies a character that does not have an encoding in the locale in effect when these <backslash>-escape sequences are processed, the result is implementation-defined. However, implementations shall not replace an unsupported character with bytes that do not form valid characters in that locale’s character set.

If a <backslash>-escape sequence represents a single-quote character (for example '), that sequence shall not terminate the dollar-single-quote sequence.

2.3 Token Recognition

The shell shall read its input in terms of lines. (For details about how the shell reads its input, see the description of sh.) The input lines can be of unlimited length. These lines shall be parsed using two major modes: ordinary token recognition and processing of here-documents.

When an io_here token has been recognized by the grammar (see 2.10 Shell Grammar), one or more of the subsequent lines immediately following the next NEWLINE token form the body of a here-document and shall be parsed according to the rules of 2.7.4 Here-Document. Any non-NEWLINE tokens (including more io_here tokens) that are recognized while searching for the next NEWLINE token shall be saved for processing after the here-document has been parsed. If a saved token is an io_here token, the corresponding here-document shall start on the line immediately following the line containing the trailing delimiter of the previous here-document. If any saved token includes a <newline> character, the behavior is unspecified.

When it is not processing an io_here, the shell shall break its input into tokens by applying the first applicable rule below to each character in turn in its input. At the start of input or after a previous token has just been delimited, the first or next token, respectively, shall start with the first character that has not already been included in a token and is not discarded according to the rules below. Once a token has started, zero or more characters from the input shall be appended to the token until the end of the token is delimited according to one of the rules below. When both the start and end of a token have been delimited, the characters forming the token shall be exactly those in the input between the two delimiters, including any quoting characters. If a rule below indicates that a token is delimited, and no characters have been included in the token, that empty token shall be discarded.

If the end of input is recognized, the current token (if any) shall be delimited. 1.

If the previous character was used as part of an operator and the current character is not quoted and can be used with the previous characters to form an operator, it shall be used as part of that (operator) token. 1.

If the previous character was used as part of an operator and the current character cannot be used with the previous characters to form an operator, the operator containing the previous character shall be delimited. 1.

If the current character is an unquoted <backslash>, single-quote, or double-quote or is the first character of an unquoted <dollar-sign> single-quote sequence, it shall affect quoting for subsequent characters up to the end of the quoted text. The rules for quoting are as described in 2.2 Quoting. During token recognition no substitutions shall be actually performed, and the result token shall contain exactly the characters that appear in the input unmodified, including any embedded or enclosing quotes or substitution operators, between the start and the end of the quoted text. The token shall not be delimited by the end of the quoted field. 1.

If the current character is an unquoted ‘$’ or ‘`’, the shell shall identify the start of any candidates for parameter expansion ( 2.6.2 Parameter Expansion), command substitution ( 2.6.3 Command Substitution), or arithmetic expansion ( 2.6.4 Arithmetic Expansion) from their introductory unquoted character sequences: ‘$’ or "${", "$(" or ‘`’, and "$((", respectively. The shell shall read sufficient input to determine the end of the unit to be expanded (as explained in the cited sections). While processing the characters, if instances of expansions or quoting are found nested within the substitution, the shell shall recursively process them in the manner specified for the construct that is found. For "$(" and ‘`’ only, if instances of io_here tokens are found nested within the substitution, they shall be parsed according to the rules of 2.7.4 Here-Document; if the terminating ‘)’ or ‘`’ of the substitution occurs before the NEWLINE token marking the start of the here-document, the behavior is unspecified. The characters found from the beginning of the substitution to its end, allowing for any recursion necessary to recognize embedded constructs, shall be included unmodified in the result token, including any embedded or enclosing substitution operators or quotes. The token shall not be delimited by the end of the substitution. 1.

If the current character is not quoted and can be used as the first character of a new operator, the current token (if any) shall be delimited. The current character shall be used as the beginning of the next (operator) token. 1.

If the current character is an unquoted <blank>, any token containing the previous character is delimited and the current character shall be discarded. 1.

If the previous character was part of a word, the current character shall be appended to that word. 1.

If the current character is a ‘#’, it and all subsequent characters up to, but excluding, the next <newline> shall be discarded as a comment. The <newline> that ends the line is not considered part of the comment. 1.

The current character is used as the start of a new word.

Once a token is delimited, it is categorized as required by the grammar in 2.10 Shell Grammar.

In situations where the shell parses its input as a program, once a complete_command has been recognized by the grammar (see 2.10 Shell Grammar), the complete_command shall be executed before the next complete_command is tokenized and parsed.

2.3.1 Alias Substitution

After a token has been categorized as type TOKEN (see 2.10.1 Shell Grammar Lexical Conventions), including (recursively) any token resulting from an alias substitution, the TOKEN shall be subject to alias substitution if all of the following conditions are true:

The TOKEN does not contain any quoting characters.

The TOKEN is a valid alias name (see XBD 3.10 Alias Name).

An alias with that name is in effect.

The TOKEN did not either fully or, optionally, partially result from an alias substitution of the same alias name at any earlier recursion level.

Either the TOKEN is being considered for alias substitution because it follows an alias substitution whose replacement value ended with a <blank> (see below) or the TOKEN could be parsed as the command name word of a simple command (see 2.10 Shell Grammar), based on this TOKEN and the tokens (if any) that preceded it, but ignoring whether any subsequent characters would allow that. except that if the TOKEN meets the above conditions and would be recognized as a reserved word (see 2.4 Reserved Words) if it occurred in an appropriate place in the input, it is unspecified whether the TOKEN is subject to alias substitution.

When a TOKEN is subject to alias substitution, the value of the alias shall be processed as if it had been read from the input instead of the TOKEN, with token recognition (see 2.3 Token Recognition) resuming at the start of the alias value. When the end of the alias value is reached, the shell may behave as if an additional <space> character had been read from the input after the TOKEN that was replaced. If it does not add this <space>, it is unspecified whether the current token is delimited before token recognition is applied to the character (if any) that followed the TOKEN in the input.

Note: A future version of this standard may disallow adding this <space>.

If the value of the alias replacing the TOKEN ends in a <blank> that would be unquoted after substitution, and optionally if it ends in a <blank> that would be quoted after substitution, the shell shall check the next token in the input, if it is a TOKEN, for alias substitution; this process shall continue until a TOKEN is found that is not a valid alias or an alias value does not end in such a <blank>.

An implementation may defer the effect of a change to an alias but the change shall take effect no later than the completion of the currently executing complete_command (see 2.10 Shell Grammar). Changes to aliases shall not take effect out of order. Implementations may provide predefined aliases that are in effect when the shell is invoked.

When used as specified by this volume of POSIX.1-2024, alias definitions shall not be inherited by separate invocations of the shell or by the utility execution environments invoked by the shell; see 2.13 Shell Execution Environment .

2.4 Reserved Words

Reserved words are words that have special meaning to the shell; see 2.9 Shell Commands. The following words shall be recognized as reserved words:

** ! { } case **	** do done elif else **	** esac fi for if **	** in then until while **

This recognition shall only occur when none of the characters is quoted and when the word is used as:

• The first word of a command
• The first word following one of the reserved words other than case, for, or in
• The third word in a case command (only in is valid in this case)
• The third word in a for command (only in and do are valid in this case)

See the grammar in 2.10 Shell Grammar.

When used in circumstances where reserved words are recognized (described above), the following words may be recognized as reserved words, in which case the results are unspecified except as described below for time:

[[	]]	function	namespace	select	time

When the word time is recognized as a reserved word in circumstances where it would, if it were not a reserved word, be the command name (see 2.9.1.1 Order of Processing) of a simple command that would execute the time utility in a manner other than one for which time states that the results are unspecified, the behavior shall be as specified for the time utility.

When used in circumstances where reserved words are recognized (described above), all words whose final character is a <colon> (‘:’) are reserved; their use in those circumstances produces unspecified results.

2.5 Parameters and Variables

A parameter can be denoted by a name, a number, or one of the special characters listed in 2.5.2 Special Parameters. A variable is a parameter denoted by a name.

A parameter is set if it has an assigned value (null is a valid value). Once a variable is set, it can only be unset by using the unset special built-in command.

Parameters can contain arbitrary byte sequences, except for the null byte. The shell shall process their values as characters only when performing operations that are described in this standard in terms of characters.

2.5.1 Positional Parameters

A positional parameter is a parameter denoted by a decimal representation of a positive integer. The digits denoting the positional parameters shall always be interpreted as a decimal value, even if there is a leading zero. When a positional parameter with more than one digit is specified, the application shall enclose the digits in braces (see 2.6.2 Parameter Expansion).

Examples:

• "$8", "${8}", "${08}", "${008}", etc. all expand to the value of the eighth positional parameter.
• "${10}" expands to the value of the tenth positional parameter.
• "$10" expands to the value of the first positional parameter followed by the character ‘0’.

Note: 0 is a special parameter, not a positional parameter, and therefore the results of expanding ${00} are unspecified.

Positional parameters are initially assigned when the shell is invoked (see sh), temporarily replaced when a shell function is invoked (see 2.9.5 Function Definition Command), and can be reassigned with the set special built-in command.

2.5.2 Special Parameters

Listed below are the special parameters and the values to which they shall expand. Only the values of the special parameters are listed; see 2.6 Word Expansions for a detailed summary of all the stages involved in expanding words.

@ Expands to the positional parameters, starting from one, initially producing one field for each positional parameter that is set. When the expansion occurs in a context where field splitting will be performed, any empty fields may be discarded and each of the non-empty fields shall be further split as described in 2.6.5 Field Splitting. When the expansion occurs within double-quotes, the behavior is unspecified unless one of the following is true:

• Field splitting as described in 2.6.5 Field Splitting would be performed if the expansion were not within double-quotes (regardless of whether field splitting would have any effect; for example, if IFS is null).
• The double-quotes are within the word of a ${parameter:-word} or a ${parameter:+word} expansion (with or without the <colon>; see 2.6.2 Parameter Expansion) which would have been subject to field splitting if parameter had been expanded instead of word.

If one of these conditions is true, the initial fields shall be retained as separate fields, except that if the parameter being expanded was embedded within a word, the first field shall be joined with the beginning part of the original word and the last field shall be joined with the end part of the original word. In all other contexts the results of the expansion are unspecified. If there are no positional parameters, the expansion of ‘@’ shall generate zero fields, even when ‘@’ is within double-quotes; however, if the expansion is embedded within a word which contains one or more other parts that expand to a quoted null string, these null string(s) shall still produce an empty field, except that if the other parts are all within the same double-quotes as the ‘@’, it is unspecified whether the result is zero fields or one empty field.

* Expands to the positional parameters, starting from one, initially producing one field for each positional parameter that is set. When the expansion occurs in a context where field splitting will be performed, any empty fields may be discarded and each of the non-empty fields shall be further split as described in 2.6.5 Field Splitting. When the expansion occurs in a context where field splitting will not be performed, the initial fields shall be joined to form a single field with the value of each parameter separated by the first character of the IFS variable if IFS contains at least one character, or separated by a <space> if IFS is unset, or with no separation if IFS is set to a null string. # Expands to the shortest representation of the decimal number of positional parameters. The command name (parameter 0) shall not be counted in the number given by ‘#’ because it is a special parameter, not a positional parameter. ? Expands to the shortest representation of the decimal exit status (see 2.8.2 Exit Status for Commands) of the pipeline (see 2.9.2 Pipelines) executed from the current shell execution environment (not a subshell environment) that most recently either terminated or, optionally but only if the shell is interactive and job control is enabled, was stopped by a signal. If this pipeline terminated, the status value shall be its exit status; otherwise, the status value shall be the same as the exit status that would have resulted if the pipeline had been terminated by a signal with the same number as the signal that stopped it. The value of the special parameter ‘?’ shall be set to 0 during initialization of the shell. When a subshell environment is created, the value of the special parameter ‘?’ from the invoking shell environment shall be preserved in the subshell.

Note: In var=$(some_command); echo $? the output is the exit status of some_command, which is executed in a subshell environment, but this is because its exit status becomes the exit status of the assignment command var=$(some_command) (see 2.9.1 Simple Commands) and this assignment command is the most recently completed pipeline. Likewise for any pipeline consisting entirely of a simple command that has no command word, but contains one or more command substitutions. (See 2.9.1 Simple Commands.)

• (Hyphen.) Expands to the current option flags (the single-letter option names concatenated into a string) as specified on invocation, by the set special built-in command, or implicitly by the shell. It is unspecified whether the -c and -s options are included in the expansion of "$-". The -i option shall be included in "$-" if the shell is interactive, regardless of whether it was specified on invocation. $ Expands to the shortest representation of the decimal process ID of the invoked shell. In a subshell (see 2.13 Shell Execution Environment), ‘$’ shall expand to the same value as that of the current shell. ! Expands to the shortest representation of the decimal process ID associated with the most recent asynchronous AND-OR list (see 2.9.3.1 Asynchronous AND-OR Lists) executed from the current shell execution environment, or to the shortest representation of the decimal process ID of the last command specified in the currently executing pipeline in the job-control background job that most recently resumed execution through the use of bg, whichever is the most recent. 0 (Zero.) Expands to the name of the shell or shell script. See sh for a detailed description of how this name is derived.

See the description of the IFS variable in 2.5.3 Shell Variables.

2.5.3 Shell Variables

Variables shall be initialized from the environment (as defined by XBD 8. Environment Variables and the exec function in the System Interfaces volume of POSIX.1-2024) and can be given new values with variable assignment commands. Shell variables shall be initialized only from environment variables that have valid names. If a variable is initialized from the environment, it shall be marked for export immediately; see the export special built-in. New variables can be defined and initialized with variable assignments, with the read or getopts utilities, with the name parameter in a for loop, with the ${name=word} expansion, or with other mechanisms provided as implementation extensions.

The following variables shall affect the execution of the shell:

ENV [UP] The processing of the ENV shell variable shall be supported if the system supports the User Portability Utilities option.

This variable, when and only when an interactive shell is invoked, shall be subjected to parameter expansion (see 2.6.2 Parameter Expansion) by the shell and the resulting value shall be used as a pathname of a file. Before any interactive commands are read, the shell shall tokenize (see 2.3 Token Recognition) the contents of the file, parse the tokens as a program (see 2.10 Shell Grammar), and execute the resulting commands in the current environment. (In other words, the contents of the ENV file are not parsed as a single compound_list. This distinction matters because it influences when aliases take effect.) The file need not be executable. If the expanded value of ENV is not an absolute pathname, the results are unspecified. ENV shall be ignored if the user’s real and effective user IDs or real and effective group IDs are different.

HOME The pathname of the user’s home directory. The contents of HOME are used in tilde expansion (see 2.6.1 Tilde Expansion). IFS A string treated as a list of characters that is used for field splitting, expansion of the ‘*’ special parameter, and to split lines into fields with the read utility. If the value of IFS includes any bytes that do not form part of a valid character, the results of field splitting, expansion of ‘*’, and use of the read utility are unspecified.

If IFS is not set, it shall behave as normal for an unset variable, except that field splitting by the shell and line splitting by the read utility shall be performed as if the value of IFS is <space><tab><newline>; see 2.6.5 Field Splitting.

The shell shall set IFS to <space><tab><newline> when it is invoked.

LANG Provide a default value for the internationalization variables that are unset or null. (See XBD 8.2 Internationalization Variables for the precedence of internationalization variables used to determine the values of locale categories.) LC_ALL The value of this variable overrides the LC_* variables and LANG , as described in XBD 8. Environment Variables. LC_COLLATE Determine the behavior of range expressions, equivalence classes, and multi-character collating elements within pattern matching. LC_CTYPE Determine the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters), which characters are defined as letters (character class alpha) and <blank> characters (character class blank), and the behavior of character classes within pattern matching. Changing the value of LC_CTYPE after the shell has started shall not affect the lexical processing of shell commands in the current shell execution environment or its subshells. Invoking a shell script or performing exec sh subjects the new shell to the changes in LC_CTYPE . LC_MESSAGES Determine the language in which messages should be written. LINENO [UP] The processing of the LINENO shell variable shall be supported if the system supports the User Portability Utilities option.

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 LINENO , 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 LINENO is unspecified.

NLSPATH [XSI] Determine the location of message catalogs for the processing of LC_MESSAGES . PATH A string formatted as described in XBD 8. Environment Variables, used to effect command interpretation; see 2.9.1.4 Command Search and Execution. PPID Set by the shell to the decimal value of its parent process ID during initialization of the shell. In a subshell (see 2.13 Shell Execution Environment), PPID shall be set to the same value as that of the parent of the current shell. For example, echo $PPID and (echo $PPID ) would produce the same value. PS1 [UP] The processing of the PS1 shell variable shall be supported if the system supports the User Portability Utilities option.

Each time an interactive shell is ready to read a command, the value of this variable shall be subjected to parameter expansion (see 2.6.2 Parameter Expansion) and exclamation-mark expansion (see below). Whether the value is also subjected to command substitution (see 2.6.3 Command Substitution) or arithmetic expansion (see 2.6.4 Arithmetic Expansion) or both is unspecified. After expansion, the value shall be written to standard error.

The expansions shall be performed in two passes, where the result of the first pass is input to the second pass. One of the passes shall perform only the exclamation-mark expansion described below. The other pass shall perform the other expansion(s) according to the rules in 2.6 Word Expansions. Which of the two passes is performed first is unspecified.

The default value shall be "$ ". For users who have specific additional implementation-defined privileges, the default may be another, implementation-defined value.

Exclamation-mark expansion: The shell shall replace each instance of the <exclamation-mark> character (‘!’) with the history file number (see Command History List) of the next command to be typed. An <exclamation-mark> character escaped by another <exclamation-mark> character (that is, "!!") shall expand to a single <exclamation-mark> character.

PS2 [UP] The processing of the PS2 shell variable shall be supported if the system supports the User Portability Utilities option.

Each time the user enters a <newline> prior to completing a command line in an interactive shell, the value of this variable shall be subjected to parameter expansion (see 2.6.2 Parameter Expansion). Whether the value is also subjected to command substitution (see 2.6.3 Command Substitution) or arithmetic expansion (see 2.6.4 Arithmetic Expansion) or both is unspecified. After expansion, the value shall be written to standard error. The default value shall be "> ".

PS4 [UP] The processing of the PS4 shell variable shall be supported if the system supports the User Portability Utilities option.

When an execution trace (set -x) is being performed, before each line in the execution trace, the value of this variable shall be subjected to parameter expansion (see 2.6.2 Parameter Expansion). Whether the value is also subjected to command substitution (see 2.6.3 Command Substitution) or arithmetic expansion (see 2.6.4 Arithmetic Expansion) or both is unspecified. After expansion, the value shall be written to standard error. The default value shall be "+ ".

PWD Set by the shell and by the cd utility. In the shell the value shall be initialized from the environment as follows. If a value for PWD is passed to the shell in the environment when it is executed, the value is an absolute pathname of the current working directory that is no longer than {PATH_MAX} bytes including the terminating null byte, and the value does not contain any components that are dot or dot-dot, then the shell shall set PWD to the value from the environment. Otherwise, if a value for PWD is passed to the shell in the environment when it is executed, the value is an absolute pathname of the current working directory, and the value does not contain any components that are dot or dot-dot, then it is unspecified whether the shell sets PWD to the value from the environment or sets PWD to the pathname that would be output by pwd -P. Otherwise, the sh utility sets PWD to the pathname that would be output by pwd -P. In cases where PWD is set to the value from the environment, the value can contain components that refer to files of type symbolic link. In cases where PWD is set to the pathname that would be output by pwd -P, if there is insufficient permission on the current working directory, or on any parent of that directory, to determine what that pathname would be, the value of PWD is unspecified. Assignments to this variable may be ignored. If an application sets or unsets the value of PWD , the behaviors of the cd and pwd utilities are unspecified.

2.6 Word Expansions

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 and elsewhere in this chapter. The expansions that are performed for a given word shall be performed in the following order:

1. Tilde expansion (see 2.6.1 Tilde Expansion), parameter expansion (see 2.6.2 Parameter Expansion), command substitution (see 2.6.3 Command Substitution ), and arithmetic expansion (see 2.6.4 Arithmetic Expansion) shall be performed, beginning to end. See item 5 in 2.3 Token Recognition.
2. Field splitting (see 2.6.5 Field Splitting) shall be performed on the portions of the fields generated by step 1.
3. Pathname expansion (see 2.6.6 Pathname Expansion) shall be performed, unless set -f is in effect.
4. Quote removal (see 2.6.7 Quote Removal), if performed, shall always be performed last.

Tilde expansions, parameter expansions, command substitutions, arithmetic expansions, and quote removals that occur within a single word shall expand to a single field, except as described below. The shell shall create multiple fields or no fields from a single word only as a result of field splitting, pathname expansion, or the following cases:

1. Parameter expansion of the special parameters ‘@’ and ‘*’, as described in 2.5.2 Special Parameters, can create multiple fields or no fields from a single word.
2. When the expansion occurs in a context where field splitting will be performed, a word that contains all of the following somewhere within it, before any expansions are applied, in the order specified:

• an unquoted <left-curly-bracket> (‘{’) that is not immediately preceded by an unquoted <dollar-sign> (‘$’)
• one or more unquoted <comma> (‘,’) characters or a sequence that consists of two adjacent <period> (‘.’) characters surrounded by other characters (which can also be <period> characters)
• an unquoted <right-curly-bracket> (‘}’)

may be subject to an additional implementation-defined form of expansion that can create multiple fields from a single word. This expansion, if supported, shall be applied before all the other word expansions are applied. The other expansions shall then be applied to each field that results from this expansion.

When the expansions in this section are performed other than in the context of preparing a command for execution, they shall be carried out in the current shell execution environment.

When expanding words for a command about to be executed, and the word will be the command name or an argument to the command, the expansions shall be carried out in the current shell execution environment. (The environment for the command to be executed is unknown until the command word is known.)

When expanding the words in a command about to be executed that are used with variable assignments or redirections, it is unspecified whether the expansions are carried out in the current execution environment or in the environment of the command about to be executed.

The ‘$’ character is used to introduce parameter expansion, command substitution, or arithmetic evaluation. If a ‘$’ that is neither within single-quotes nor escaped by a <backslash> is immediately followed by a character that is not a <space>, not a <tab>, not a <newline>, and is not one of the following:

• A numeric character
• The name of one of the special parameters (see 2.5.2 Special Parameters)
• A valid first character of a variable name
• A <left-curly-bracket> (‘{’)
• A <left-parenthesis>
• A single-quote

the result is unspecified. If a ‘$’ that is neither within single-quotes nor escaped by a <backslash> is immediately followed by a <space>, <tab>, or a <newline>, or is not followed by any character, the ‘$’ shall be treated as a literal character.

2.6.1 Tilde Expansion

A "tilde-prefix" consists of an unquoted <tilde> character at the beginning of a word, followed by all of the characters preceding the first unquoted <slash> in the word, or all the characters in the word if there is no <slash>. In an assignment (see XBD 4.26 Variable Assignment), multiple tilde-prefixes can be used: one at the beginning of the word (that is, following the <equals-sign> of the assignment), or one following any unquoted <colon>, or both. A tilde-prefix in an assignment is terminated by the first unquoted <colon> or <slash>, or the end of the assignment word.

If the tilde-prefix consists of only the <tilde> character, it shall be replaced by the value of the variable HOME . If HOME is unset, the results are unspecified.

Otherwise, the characters in the tilde-prefix following the <tilde> shall be treated as a possible login name from the user database. If these characters do not form a portable login name (see the description of the LOGNAME environment variable in XBD 8.3 Other Environment Variables), the results are unspecified.

Note: Since the tilde-prefix is not subject to further word expansions after the <tilde> is removed to obtain the login name, none of the following has a portable login name following the <tilde>:

~"string"
~'string'
~$var
~\/bin

owing to the presence of ‘"’, ‘'’, ‘$’, ‘\’, and ‘/’ characters in the login name.

If the characters in the tilde-prefix following the <tilde> form a portable login name, the tilde-prefix shall be replaced by a pathname of the initial working directory associated with the login name. The pathname shall be obtained as if by using the getpwnam() function as defined in the System Interfaces volume of POSIX.1-2024. If the system does not recognize the login name, the results are unspecified.

The pathname that replaces the tilde-prefix shall be treated as if quoted to prevent