This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for an executable file known only by a filename. The prefixes shall be separated by a <colon> (’:’). When a nonzero-length prefix is applied to this filename, a <slash> shall be inserted between the prefix and the filename if the prefix did not end in <slash>. A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent <colon> characters ("::"), as an initial <colon> preceding the rest of the list, or as a trailing <colon> following the rest of the list. A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH. The list shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found. If the pathname being sought contains a <slash>, the search through the path prefixes shall not be performed. If the pathname begins with a <slash>, the specified path is resolved (see Section 4.12, on page 111). If PATH is unset or is set to null, the path search is implementation-defined.

Since <colon> is a separator in this context, directory names that might be used in PATH should not include a <colon> character.

This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for built-ins and executable files known only by a filename. The prefixes shall be separated by a <colon> (’:’). When a nonzero-length prefix is applied to this filename, a <slash> shall be inserted between the prefix and the filename if the prefix did not end in <slash>. A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent <colon> characters ("::"), as an initial <colon> preceding the rest of the list, or as a trailing <colon> following the rest of the list. A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH. The list shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found; or, if the shell is performing the search, a built-in associated with that prefix and filename has been found. If the pathname being sought contains a <slash>, the search through the path prefixes shall not be performed. If the pathname begins with a <slash>, the specified path is resolved (see Section 4.12, on page 111). If PATH is unset or is set to null, or if a path prefix in PATH contains a <percent-sign> character ('%'), the path search is implementation-defined.

Since <colon> is a separator in this context, directory names that might be used in PATH should not include a <colon> character. Since <percent-sign> may have an implementation-defined meaning when searching for built-in utilities, directory names in PATH that will be used to search for non-built-in utilities should not contain a <percent-sign> character.

The standard specifies that (when no <slash> character is included in a command pathname) special built-in utilities and the standard utilities listed in the table in XREF to XCU subclause 2.9.1.1 Command Search and Execution item 1.c. are not subject to a search using PATH. All other standard utilities, even if implemented as shell built-ins, are required to be found by searching PATH. This means that if a shell includes a built-in for a standard utility that is not in the list above, a user is allowed to write a utility that will override that built-in. The standard also requires that all standard utilities can be executed by commands like:

find . -type d -exec printf 'Found directory: %s\n' '{}' +

So, other than differences caused by using different shell execution environments, a standard utility that is implemented as a built-in and the non-built-in version of that standard utility are both required to behave as the standard specifies. But, if a non-standard utility is found in PATH before the standard utility's location in PATH, the non-standard utility must be invoked rather than the built-in. For instance, if the shell includes a built-in printf utility (which most shells do), PATH is initialized using:

PATH="$HOME/bin:$(command -p getconf PATH)"

and

$HOME/bin/printf

is an executable file containing:

command -p printf 'In %s with args:\n' "${0##*/}" >&2
command -p printf '\t%s\n' "$@" >&2
command -V printf >&2
command -Vp printf >&2
command -p printf "$@"

then the command:

printf '%s %s\n' HOME "$HOME" PATH "$PATH"

should produce output similar to:

In printf with args:
    %s %s\n
    HOME
    /Users/dwc
    PATH
    /Users/dwc/bin:/usr/bin:/bin:/usr/sbin:/sbin
printf is a tracked alias for /Users/dwc/bin/printf
printf is a shell builtin
HOME /Users/dwc
PATH /Users/dwc/bin:/usr/bin:/bin:/usr/sbin:/sbin

The current version of the Korn shell installs built-ins into the shell using a builtin utility that allows the built-in to be associated with the pathname of the non-built-in version of that utility. (Unfortunately, some implementations that use ksh93 as their standard sh utility, do not make use of this feature and incorrectly install built-ins for standard utilities that are not associated with a PATH search. And, most other shells incorrectly always use a built-in utility if one is installed, even when it should be overridden by a PATH search that should find the non-standard version of a utility with the name of that built-in.) Some other shells use a <percent-sign> character in a directory pathname in PATH to indicate one or more directories that should be used when processing PATH to determine when standard utilities (other than those listed in the table in XCU subclause 2.9.1.1 item 1.c.) should be found. The POSIX.1-201x revision of the standard allows either of these methods to be used to install built-ins that meet the requirements stated in XCU subclause 2.9.1.1 by making the behavior of the built-in path search implementation-defined when a <percent-sign> character is found in PATH.

The list shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found. If the shell is performing the search, a built-in associated with the filename then the shell shall select that built-in

The list shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found; or, if the shell is performing the search, a built-in associated with that prefix and filename has been found.

There is a proposal being considered for the dash shell that uses a <percent-sign> character in a directory pathname in PATH to indicate one or more directories that should be used when processing PATH to determine when standard utilities (other than those listed in the table in XCU subclause 2.9.1.1 item 1.c.) should be found.

Some other shells use a <percent-sign> character in a directory pathname in PATH to indicate one or more directories that should be used when processing PATH to determine when standard utilities (other than those listed in the table in XCU subclause 2.9.1.1 item 1.c.) should be found.

• The existing normative text does not match the intended behavior described in the rationale. The normative text does not make it clear that ordinary built-ins are associated with a directory, and it says that if a non-built-in is found during a PATH search then the built-in is invoked regardless of the order of directories in PATH or the built-in's associated directory (if any). This is almost equivalent to the historical behavior of "always execute the built-in if there is one", with the only difference being the behavior when a non-built-in doesn't exist (issue 7 says to return 126 in this case).
• Many current implementations don't behave in the intended way, probably because of the wording of the current normative text. They instead skip the PATH search and execute the built-in no matter what. ksh seems to be the only exception.

On page 46 lines 1440-1443 (XBD 3.83 definition of Built-In Utility), change:

A utility implemented within a shell. The utilities referred to as special built-ins have special qualities. Unless qualified, the term "built-in" includes the special built-in utilities. Regular built-ins are not required to be actually built into the shell on the implementation, but they do have special command-search qualities.

Note: Special Built-In Utilities are defined in detail in XCU Section 2.14 (on page 2356). Regular Built-In Utilities are defined in detail in XCU Section 2.9.1.1 (on page 2339).

to:

A utility implemented within a shell. There are two main types of built-in utilities: special built-ins and regular built-ins. Unless qualified, the term "built-in" includes both types. The utilities referred to as special built-ins have special qualities. Regular built-ins are not required to be actually built into the shell on the implementation, but they usually have special command-search qualities or affect the current execution environment.

Note: Special Built-In Utilities are defined in detail in XCU Section 2.14 (on page 2356). Regular Built-In Utilities are defined in detail in XCU Section 1.6 (on page 2319).

On page 65 after line 1901 insert a new section:

3.201 Intrinsic Utility

A utility that is not subject to a PATH search during command search, usually implemented as a regular built-in utility.

Note: Intrinsic Utilities are defined in detail in XCU Section 1.7 (on page 2319).

On page 84 after line 2374 insert a new section:

3.318 Regular Built-In Utility (or Regular Built-In)

See Built-In Utility in Section 3.83 (on page 46).

On page 2318 lines 73544-73553 (XCU 1.6 Built-In Utilities), change:

The utilities named in Table 1-5 are frequently provided in built-in form. All of the utilities named in the table have special properties in terms of command search order within the shell, as described in Section 2.9.1.1 (on page 2339).

Table 1-5 Regular Built-In Utilities

• alias
• bg
• cd
• command
• false
• fc
• fg
• getopts
• jobs
• kill
• newgrp
• pwd
• read
• true
• umask
• unalias
• wait

However, all of the standard utilities, including the regular built-ins in the table, but not the special built-ins [...]

to:

The intrinsic utilities described in Section 1.7 (on page 2318) are frequently provided as regular built-ins.

However, all of the standard utilities, including the regular built-ins but not the special built-ins [...]

On page 2319 after line 73556 insert a new section:

1.7 Intrinsic Utilities

The utilities in Table 1-5 are intrinsic utilities. As described in Section 2.9.1.1 (on page 2339), these utilities are not subject to a PATH search during command search and execution.

Table 1-5 Regular Built-In Utilities

• alias
• bg
• cd
• command
• false
• fc
• fg
• getopts
• jobs
• kill
• newgrp
• pwd
• read
• true
• umask
• unalias
• wait

Whether any additional utility is considered an intrinsic utility is implementation-defined. Because applications are unable to override an intrinsic utility with a utility from PATH, implementations are strongly encouraged to minimize the number of additional intrinsic utilities.

On page 2339 lines 74388-74389 (XCU 2.9.1.1 bullet 1.c.), change:

If the command name matches the name of a utility listed in the following table, that utility shall be invoked.

• alias
• bg
• cd
• command
• false
• fc
• fg
• getopts
• jobs
• kill
• newgrp
• pwd
• read
• true
• umask
• unalias
• wait

to:

If the command name matches the name of an intrinsic utility (see Section 1.17 on page 2319), that utility shall be invoked.

On page 3694 lines 126360-126366 (rationale for XCU 2.9.1.1), change:

The sequence selected for the Shell and Utilities volume of POSIX.1-2008 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 command 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 POSIX.1-2008, [...]

to:

The sequence selected for the Shell and Utilities volume of POSIX.1-2008 acknowledges that special built-ins cannot be overridden, but gives the programmer full control over which versions of other utilities are executed (with some exceptions). It provides a means of suppressing function lookup (via the command utility) for the user's own functions and, with the exception of the intrinsic utilities (see XCU Section 1.7), ensures that any regular built-ins or functions provided by the implementation are under the control of the path search. The mechanisms for associating non-intrinsic built-ins or functions with executable files in the path are not specified by the Shell and Utilities volume of POSIX.1-2008, [...]

On page 2340 lines 74397-74398 (XCU 2.9.1.1 bullet 1.d.i.a.), change:

If the system has implemented the utility as a regular built-in or as a shell function, it shall be invoked at this point in the path search.

to:

If the system has implemented the utility as a built-in or as a shell function, and the built-in or function is associated with the directory that was most recently tested during the successful PATH search, that built-in or function shall be invoked.

1. Utility names should be between two and nine characters, inclusive.


2. Utility names should include lowercase letters (the lower character classification) and digits only from the portable character set.

getconf PATH

A utility implemented within a shell. The utilities referred to as special built-ins have special qualities. Unless qualified, the term "built-in" includes the special built-in utilities. Regular built-ins are not required to be actually built into the shell on the implementation, but they do have special command-search qualities.

Note: Special Built-In Utilities are defined in detail in XCU Section 2.14 (on page 2356). Regular Built-In Utilities are defined in detail in XCU Section 2.9.1.1 (on page 2339).

A utility implemented within a shell. There are two main types of built-in utilities: special built-ins and regular built-ins. Unless qualified, the term "built-in" includes both types. The utilities referred to as special built-ins have special qualities. Regular built-ins are not required to be actually built into the shell on the implementation, but they usually have special command-search qualities or affect the current execution environment.

Note: Special Built-In Utilities are defined in detail in XCU Section 2.14 (on page 2356). Regular Built-In Utilities are defined in detail in XCU Section 1.6 (on page 2318).

3.201 Intrinsic Utility

A utility that is not subject to a PATH search during command search, usually implemented as a regular built-in utility.

Note: Intrinsic Utilities are defined in detail in XCU Section 1.7 (on page 2318).

3.318 Regular Built-In Utility (or Regular Built-In)

See Built-In Utility in Section 3.83 (on page 46).

This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for an executable file known only by a filename. The prefixes shall be separated by a <colon> (’:’). When a nonzero-length prefix is applied to this filename, a <slash> shall be inserted between the prefix and the filename if the prefix did not end in <slash>. A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent <colon> characters ("::"), as an initial <colon> preceding the rest of the list, or as a trailing <colon> following the rest of the list. A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH. The list shall be searched from beginning to end, applying the filename to each prefix, until an executable file with the specified name and appropriate execution permissions is found. If the pathname being sought contains a <slash>, the search through the path prefixes shall not be performed. If the pathname begins with a <slash>, the specified path is resolved (see Section 4.12, on page 111). If PATH is unset or is set to null, the path search is implementation-defined.

Since <colon> is a separator in this context, directory names that might be used in PATH should not include a <colon> character.

This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for built-ins and executable files known only by a filename. The prefixes shall be separated by a <colon> (’:’). When a nonzero-length prefix is applied to this filename, a <slash> shall be inserted between the prefix and the filename if the prefix did not end in <slash>. A zero-length prefix is a legacy feature that indicates the current working directory. It appears as two adjacent <colon> characters ("::"), as an initial <colon> preceding the rest of the list, or as a trailing <colon> following the rest of the list. A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH. The list shall be searched from beginning to end, applying the filename to each prefix, until either an executable file with the specified name and appropriate execution permissions is found or, if the shell is performing the search, a built-in associated with that prefix and filename is found. If the pathname being sought contains a <slash>, the search through the path prefixes shall not be performed. If the pathname begins with a <slash>, the specified path shall be resolved (see Section 4.12, on page 111). If PATH is unset or is set to null, or if a path prefix in PATH contains a <percent-sign> character ('%'), the path search is implementation-defined.

Since <colon> is a separator in this context, directory names that might be used in PATH should not include a <colon> character. Since <percent-sign> may have an implementation-defined meaning when searching for built-in utilities, directory names in PATH that will be used to search for non-built-in utilities should not contain a <percent-sign> character.

The utilities named in Table 1-5 are frequently provided in built-in form. All of the utilities named in the table have special properties in terms of command search order within the shell, as described in Section 2.9.1.1 (on page 2339).

Table 1-5 Regular Built-In Utilities

• alias
• bg
• cd
• command
• false
• fc
• fg
• getopts
• jobs
• kill
• newgrp
• pwd
• read
• true
• umask
• unalias
• wait

However, all of the standard utilities, including the regular built-ins in the table, but not the special built-ins [...]

The intrinsic utilities described in Section 1.7 (on page 2318) are frequently provided as regular built-ins.

However, all of the standard utilities, including the regular built-ins but not the special built-ins [...]

1.7 Intrinsic Utilities

As described in Section 2.9.1.1 (on page 2339), intrinsic utilities are not subject to a PATH search during command search and execution. The utilities in Table 1-5 shall be intrinsic utilities.

Table 1-5 Intrinsic Utilities

• alias
• bg
• cd
• command
• fc
• fg
• getopts
• hash
• jobs
• kill
• read
• [XSI]type[/XSI]
• [XSI]ulimit[/XSI]
• umask
• unalias
• wait

Whether any additional utility is considered an intrinsic utility is implementation-defined. Because applications are unable to override an intrinsic utility with a utility from PATH, implementations should not make any utility an intrinsic utility beyond the utilities in Table 1-5.

If the command name matches the name of a utility listed in the following table, that utility shall be invoked.

• alias
• bg
• cd
• command
• false
• fc
• fg
• getopts
• jobs
• kill
• newgrp
• pwd
• read
• true
• umask
• unalias
• wait

If the command name matches the name of an intrinsic utility (see Section 1.7 on page 2318), that utility shall be invoked.

If the system has implemented the utility as a regular built-in or as a shell function, it shall be invoked at this point in the path search.

If the system has implemented the utility as a built-in or as a shell function, and the built-in or function is associated with the directory that was most recently tested during the successful PATH search, that built-in or function shall be invoked.

The standard specifies that (when no <slash> character is included in a command pathname) special built-in utilities and intrinsic utilities are not subject to a search using PATH. All other standard utilities, even if implemented as shell built-ins, are required to be found by searching PATH. This means that if a shell includes a built-in for a standard utility that is not intrinsic, a user can write a utility that will override that built-in. The standard also requires that all standard utilities can be executed by commands like:

find . -type d -exec printf 'Found directory: %s\n' '{}' +

So, other than differences caused by using different shell execution environments, a standard utility that is implemented as a built-in and the non-built-in version of that standard utility are both required to behave as the standard specifies. But, if a non-standard utility is found in PATH before the standard utility's location in PATH, the non-standard utility must be invoked rather than the built-in. For instance, if the shell includes a built-in printf utility (which most shells do), PATH is initialized using:

PATH="$HOME/bin:$(command -p getconf PATH)"

and <tt>$HOME/bin/printf</tt> is an executable file containing:

command -p printf 'In %s with args:\n' "${0##*/}" >&2
command -p printf '\t%s\n' "$@" >&2
command -V printf >&2
command -Vp printf >&2
command -p printf "$@"

then the command:

printf '%s %s\n' HOME "$HOME" PATH "$PATH"

should produce output similar to:

In printf with args:
    %s %s\n
    HOME
    /Users/dwc
    PATH
    /Users/dwc/bin:/usr/bin:/bin:/usr/sbin:/sbin
printf is a tracked alias for /Users/dwc/bin/printf
printf is a shell builtin
HOME /Users/dwc
PATH /Users/dwc/bin:/usr/bin:/bin:/usr/sbin:/sbin

The current version of the Korn shell installs built-ins into the shell using a builtin utility that allows the built-in to be associated with the pathname of the non-built-in version of that utility. (Unfortunately, some implementations that use ksh93 as their standard sh utility do not make use of this feature and install built-ins for standard utilities that are not associated with a PATH search. And, most other shells incorrectly always use a built-in utility if one is installed, even when it should be overridden by a PATH search that should find the non-standard version of a utility with the name of that built-in.) Some other shells use a <percent-sign> character in a directory pathname in PATH to indicate one or more directories that should be used when processing PATH to determine when non-intrinsic standard utilities should be found. The POSIX.1-201x revision of the standard allows either of these methods to be used to install built-ins that meet the requirements stated in XCU subclause 2.9.1.1 by making the behavior of the built-in path search implementation-defined when a <percent-sign> character is found in PATH.

All of these utilities can be exec-ed. There is no requirement that these utilities are actually built into the shell itself, but many shells need the capability to do so because XCU Section 2.9.1.1 (on page 2339) requires that they be found prior to the PATH search. The shell could satisfy its requirements by keeping a list of the names and directly accessing the file-system versions regardless of PATH. Providing all of the required functionality for those such as cd or read would be more difficult.

There were originally three justifications for allowing the omission of exec-able versions:

Other than the special built-in utilities, there is no requirement to build utilities into the shell itself. However, many shells implement certain utilities as regular built-ins for the following reasons:

• To improve performance, especially for frequently used lightweight utilities (such as test, true, and false).
• To eliminate the need for some sort of interprocess communication between the shell and those utilities that read or modifiy the shell's execution environment (such as cd).
• To make it easier to satisfy the command search and execution requirements in XCU Section 2.9.1.1 (on page 2339) for intrinsic utilities. Intrinsic utilities must be found prior to the PATH search. The shell could satisfy this requirement by keeping a list of the intrinsic utility pathnames and directly accessing the file-system versions regardless of PATH, but these utilities usually need to read or modify the shell's execution environment anyway.

With the exception of the intrinsic utilities, all regular built-in utilities are subject to the PATH search and can be overridden by a specially crafted PATH environment variable.

All of the regular built-in utilities can be exec-ed. There were originally three justifications for allowing the omission of exec-able versions:

C.1.8 Intrinsic Utilities

There were varying reasons for including utilities in the table of built-ins:

There were varying reasons for including utilities in the table of intrinsic utilities:

cd, getopts, newgrp, read, umask, wait

cd, getopts, hash, read, [XSI]type, ulimit,[/XSI] umask, wait

The following utilities are frequently implemented as intrinsic (and built-in) utilities. Future versions of this standard might not allow these utilities, or any other standard utility not in Table 1-5 in XCU 1.7 on page 2318, to be intrinsic; implementations are encouraged to implement these as non-intrinsic utilities instead (but still built-in if they were previously built-in).

• [
• echo
• false
• newgrp
• printf
• pwd
• test
• true

The sequence selected for the Shell and Utilities volume of POSIX.1-2008 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 command 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 POSIX.1-2008, [...]

The sequence selected for the Shell and Utilities volume of POSIX.1-2008 acknowledges that special built-ins cannot be overridden, but gives the programmer full control over which versions of other utilities are executed (with some exceptions). It provides a means of suppressing function lookup (via the command utility) for the user's own functions and, with the exception of the intrinsic utilities (see XCU Section 1.7), ensures that any regular built-ins or functions provided by the implementation are under the control of the path search. The mechanisms for associating non-intrinsic built-ins or functions with executable files in the path are not specified by the Shell and Utilities volume of POSIX.1-2008, [...]

This utility is required to be intrinsic. See section 1.7 on page 2318 for details.

• The new XCU section 1.7 was changed to remove some intrinsic utilities and add others:
  • remove false, true, newgrp, and pwd as these do not need to read/modify the shell's execution environment, and it is not important that they preempt the PATH search
  • add hash, type, and ulimit as these do need to read/modify the shell's execution environment and they are commonly implemented as intrinsic utilities
• in rationale, mention utilities that have traditionally been intrinsic (true, false, newgrp, pwd, test, echo, printf) and warn that a future version might not allow them to be intrinsic
• rationale cleanups
• minor wording fixes

• change 1.17 to 1.7 (typo fix)
• added instructions to say that the utility is intrinsic in the utility's APPLICATION USAGE section (see the last two lines of the bugnote)