The Shell and Utilities volume of POSIX.1-2024 describes the commands and utilities offered to application programs by POSIX-conformant systems.
This subsection describes some of the features provided by the System Interfaces volume of POSIX.1-2024 that are assumed to be globally available on all systems conforming to this volume of POSIX.1-2024. This subsection does not attempt to detail all of the features defined in the System Interfaces volume of POSIX.1-2024 that are required by all of the utilities defined in this volume of POSIX.1-2024; the utility and function descriptions point out additional functionality required to provide the corresponding specific features needed by each.
The following subsections describe frequently used concepts. Many of these concepts are described in the Base Definitions volume of POSIX.1-2024. Utility and function description statements override these defaults when appropriate.
The following process attributes, as described in the System Interfaces volume of POSIX.1-2024, are assumed to be supported for all processes in this volume of POSIX.1-2024:
|
|
A conforming implementation may include additional process attributes.
The following functionality of the fork() function defined in the System Interfaces volume of POSIX.1-2024 shall be available on all systems conforming to this volume of POSIX.1-2024:
The file access control mechanism described by XBD 4.7 File Access Permissions shall apply to all files on an implementation conforming to this volume of POSIX.1-2024.
If a file that does not exist is to be written, it shall be created as described below, unless the utility description states otherwise.
When a file that does not exist is created, the following features defined in the System Interfaces volume of POSIX.1-2024 shall apply unless the utility or function description states otherwise:
(see the description of File Modes in XBD 14. Headers , <sys/stat.h>) except that the bits specified by the file mode creation mask of the process shall be cleared. If the file is a directory, the permission bits shall be set to: S_IRWXU | S_IRWXG | S_IRWXO
except that the bits specified by the file mode creation mask of the process shall be cleared.
When an attempt is made to create a file that already exists, the utility shall take the action indicated in Actions when Creating a File that Already Exists corresponding to the type of the file the utility is trying to create and the type of the existing file, unless the utility description states otherwise.
Table: Actions when Creating a File that Already Exists
|
New Type |
|
|||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Existing Type |
B |
C |
D |
F |
L |
M |
P |
Q |
R |
S |
T |
Function Creating New |
|
B |
Block Special |
F |
F |
F |
F |
F |
U |
U |
U |
OF |
U |
U |
mknod()** |
C |
Character Special |
F |
F |
F |
F |
F |
U |
U |
U |
OF |
U |
U |
mknod()** |
D |
Directory |
F |
F |
F |
F |
F |
— |
— |
— |
F |
— |
U |
mkdir() |
F |
FIFO Special File |
F |
F |
F |
F |
F |
— |
— |
— |
O |
— |
U |
mkfifo() |
L |
Symbolic Link |
F |
F |
F |
F |
F |
— |
— |
— |
FL |
— |
U |
symlink() |
M |
Shared Memory |
F |
F |
F |
F |
F |
— |
— |
— |
— |
— |
U |
shm_open() |
P |
Semaphore |
F |
F |
F |
F |
F |
— |
— |
— |
— |
— |
U |
sem_open() |
Q |
Message Queue |
F |
F |
F |
F |
F |
— |
— |
— |
— |
— |
U |
mq_open() |
R |
Regular File |
F |
F |
F |
F |
F |
— |
— |
— |
RF |
— |
U |
open() |
S |
Socket |
F |
F |
F |
F |
F |
— |
— |
— |
— |
— |
U |
bind() |
T |
Typed Memory |
F |
F |
F |
F |
F |
U |
U |
U |
U |
U |
U |
* |
The following codes are used in Actions when Creating a File that Already Exists :
When a file is to be appended, the file shall be opened in a manner equivalent to using the O_APPEND flag, without the O_TRUNC flag, in the open() function defined in the System Interfaces volume of POSIX.1-2024.
When a file is to be read or written, the file shall be opened with an access mode corresponding to the operation to be performed. If file access permissions deny access, the requested operation shall fail.
When a directory that is the root directory or current working directory of any process is removed, the effect is implementation-defined. If file access permissions deny access, the requested operation shall fail. Otherwise, when a file is removed:
All files shall have the three time values described by XBD 4.12 File Times Update .
When a reference is made to the contents of a file, pathname, this means the equivalent of all of the data placed in the space pointed to by buf when performing the read() function calls in the following operations defined in the System Interfaces volume of POSIX.1-2024:
while (read (fildes, buf, nbytes) > 0) ;
If the file is indicated by a pathname pathname, the file descriptor shall be determined by the equivalent of the following operation defined in the System Interfaces volume of POSIX.1-2024:
fildes = open (pathname, O_RDONLY);
The value of nbytes in the above sequence is unspecified; if the file is of a type where the data returned by read() would vary with different values, the value shall be one that results in the most data being returned.
If the read() function calls would return an error, it is unspecified whether the contents of the file are considered to include any data from offsets in the file beyond where the error would be returned.
The pathname resolution algorithm, described by XBD 4.16 Pathname Resolution , shall be used by implementations conforming to this volume of POSIX.1-2024; see also XBD 4.8 File Hierarchy .
When the current working directory (see XBD 3.94 Current Working Directory ) is to be changed, unless the utility or function description states otherwise, the operation shall succeed unless a call to the chdir() function defined in the System Interfaces volume of POSIX.1-2024 would fail when invoked with the new working directory pathname as its argument.
The functionality of the setlocale() function defined in the System Interfaces volume of POSIX.1-2024 shall be available on all systems conforming to this volume of POSIX.1-2024; that is, utilities that require the capability of establishing an international operating environment shall be permitted to set the specified category of the international environment.
Some utility descriptions specify that a utility performs actions equivalent to a function defined in the System Interfaces volume of POSIX.1-2024. Such specifications require only that the external effects be equivalent, not that any effect within the utility and visible only to the utility be equivalent.
Some of the standard utilities perform complex data manipulation using their own procedure and arithmetic languages, as defined in their EXTENDED DESCRIPTION or OPERANDS sections. Unless otherwise noted, the arithmetic and semantic concepts (precision, type conversion, control flow, and so on) shall be equivalent to those defined in the ISO C standard, as described in the following sections. Note that there is no requirement that the standard utilities be implemented in any particular programming language.
Integer variables and constants, including the values of operands and option-arguments, used by the standard utilities listed in this volume of POSIX.1-2024 shall be implemented as equivalent to the ISO C standard signed long data type; floating point shall be implemented as equivalent to the ISO C standard double type. Conversions between types shall be as described in the ISO C standard. All variables shall be initialized to zero if they are not otherwise assigned by the input to the application.
Arithmetic operators and control flow keywords shall be implemented as equivalent to those in the cited ISO C
standard section, as listed in Selected ISO C Standard Operators and Control Flow Keywords .
Table: Selected ISO C Standard Operators and Control Flow Keywords
Operation |
ISO C Standard Equivalent Reference |
---|---|
() |
Section 6.5.1, Primary Expressions |
postfix ++ |
Section 6.5.2, Postfix Operators |
unary + |
Section 6.5.3, Unary Operators |
* |
Section 6.5.5, Multiplicative Operators |
+ |
Section 6.5.6, Additive Operators |
<< |
Section 6.5.7, Bitwise Shift Operators |
<, <= |
Section 6.5.8, Relational Operators |
== |
Section 6.5.9, Equality Operators |
& |
Section 6.5.10, Bitwise AND Operator |
^ |
Section 6.5.11, Bitwise Exclusive OR Operator |
| |
Section 6.5.12, Bitwise Inclusive OR Operator |
&& |
Section 6.5.13, Logical AND Operator |
|| |
Section 6.5.14, Logical OR Operator |
expr?expr:expr |
Section 6.5.15, Conditional Operator |
=, *=, /=, %=, +=, -= |
Section 6.5.16, Assignment Operators |
if () |
Section 6.8.4, Selection Statements |
while () |
Section 6.8.5, Iteration Statements |
goto |
Section 6.8.6, Jump Statements |
The evaluation of arithmetic expressions shall be equivalent to that described in Section 6.5, Expressions, of the ISO C standard.
Any mathematical functions with the same names as those in the following sections of the ISO C standard:
shall be implemented to return the results equivalent to those returned from a call to the corresponding function described in the ISO C standard.
This section lists magnitude limitations imposed by a specific implementation. The braces notation, {LIMIT}, is
used in this volume of POSIX.1-2024 to indicate these values, but the braces are not part of the name.
Table: Utility Limit Minimum Values
Name |
Description |
Value |
---|---|---|
{POSIX2_BC_BASE_MAX} |
The maximum obase value allowed by the bc utility. |
99 |
{POSIX2_BC_DIM_MAX} |
The maximum number of elements permitted in an array by the bc utility. |
2048 |
{POSIX2_BC_SCALE_MAX} |
The maximum scale value allowed by the bc utility. |
99 |
{POSIX2_BC_STRING_MAX} |
The maximum length of a string constant accepted by the bc utility. |
1000 |
{POSIX2_COLL_WEIGHTS_MAX} |
The maximum number of weights that can be assigned to an entry of the LC_COLLATE order keyword in the locale definition file; see the border_start keyword in XBD 7.3.2 LC_COLLATE . |
2 |
{POSIX2_EXPR_NEST_MAX} |
The maximum number of expressions that can be nested within parentheses by the expr utility. |
32 |
{POSIX2_LINE_MAX} |
Unless otherwise noted, the maximum length, in bytes, of the input line of a utility (either standard input or another file), when the utility is described as processing text files. The length includes room for the trailing <newline>. |
2048 |
{POSIX_RE_DUP_MAX} |
Maximum number of repeated occurrences of a BRE or ERE interval expression; see XBD 9.3.6 BREs Matching Multiple Characters and 9.4.6 EREs Matching Multiple Characters . |
255 |
The values specified in Utility Limit Minimum Values represent the lowest values conforming implementations shall provide and, consequently, the largest values on which an application can rely without further enquiries, as described below. These values shall be accessible to applications via the getconf utility (see getconf ).
Implementations may provide more liberal, or less restrictive, values than shown in Utility Limit Minimum Values . These possibly more liberal values are accessible using the symbols in Symbolic Utility Limits .
The sysconf() function defined in the System Interfaces volume of POSIX.1-2024 or the getconf utility return the value of each symbol on each specific implementation. The value so retrieved is the largest, or most liberal, value that is available throughout the session lifetime, as determined at session creation. The literal names shown in the table apply only to the getconf utility; the high-level language binding describes the exact form of each name to be used by the interfaces in that binding.
All numeric limits defined by the System Interfaces volume of POSIX.1-2024, such as {PATH_MAX}, shall also apply to this volume of POSIX.1-2024. All the utilities defined by this volume of POSIX.1-2024 are implicitly limited by these values, unless otherwise noted in the utility descriptions.
It is not guaranteed that the application can actually reach the specified limit of an implementation in any given
case, or at all, as a lack of virtual memory or other resources may prevent this. The limit value indicates only that the
implementation does not specifically impose any arbitrary, more restrictive limit.
Table: Symbolic Utility Limits
Name |
Description |
Minimum Value |
---|---|---|
{BC_BASE_MAX} |
The maximum obase value allowed by the bc utility. |
{POSIX2_BC_BASE_MAX} |
{BC_DIM_MAX} |
The maximum number of elements permitted in an array by the bc utility. |
{POSIX2_BC_DIM_MAX} |
{BC_SCALE_MAX} |
The maximum scale value allowed by the bc utility. |
{POSIX2_BC_SCALE_MAX} |
{BC_STRING_MAX} |
The maximum length of a string constant accepted by the bc utility. |
{POSIX2_BC_STRING_MAX} |
{COLL_WEIGHTS_MAX} |
The maximum number of weights that can be assigned to an entry of the LC_COLLATE order keyword in the locale definition file; see the order_start keyword in XBD 7.3.2 LC_COLLATE . |
{POSIX2_COLL_WEIGHTS_MAX} |
{EXPR_NEST_MAX} |
The maximum number of expressions that can be nested within parentheses by the expr utility. |
{POSIX2_EXPR_NEST_MAX} |
{LINE_MAX} |
Unless otherwise noted, the maximum length, in bytes, of the input line of a utility (either standard input or another file), when the utility is described as processing text files. The length includes room for the trailing <newline>. |
{POSIX2_LINE_MAX} |
{RE_DUP_MAX} |
Maximum number of repeated occurrences of a BRE or ERE interval expression; see XBD 9.3.6 BREs Matching Multiple Characters and 9.4.6 EREs Matching Multiple Characters . |
{POSIX_RE_DUP_MAX} |
The following value may be a constant within an implementation or may vary from one pathname to another.
Portions of this volume of POSIX.1-2024 are expressed in terms of a special grammar notation. It is used to portray the complex syntax of certain program input. The grammar is based on the syntax used by the yacc utility. However, it does not represent fully functional yacc input, suitable for program use; the lexical processing and all semantic requirements are described only in textual form. The grammar is not based on source used in any traditional implementation and has not been tested with the semantic code that would normally be required to accompany it. Furthermore, there is no implication that the partial yacc code presented represents the most efficient, or only, means of supporting the complex syntax within the utility. Implementations may use other programming languages or algorithms, as long as the syntax supported is the same as that represented by the grammar.
The following typographical conventions are used in the grammar; they have no significance except to aid in reading.
This section describes all of the subsections used within the utility descriptions, including:
As stated in 1.1.1.11 Actions Equivalent to Functions , some functions are described in terms of equivalent functionality. When specific functions are cited, the implementation shall provide equivalent functionality including side-effects associated with successful execution of the function. The treatment of errors and intermediate results from the individual functions cited is generally not specified by this volume of POSIX.1-2024. See the utility's EXIT STATUS and CONSEQUENCES OF ERRORS sections for all actions associated with errors encountered by the utility.
A standard utility shall not be treated as a declaration utility unless explicitly stated in this section.
Each OPTIONS section that uses the phrase "The ... utility shall conform to the Utility Syntax Guidelines ..." refers only to the use of the utility as specified by this volume of POSIX.1-2024; implementation extensions should also conform to the guidelines, but may allow exceptions for historical practice.
Unless otherwise stated in the utility description, when given an option unrecognized by the implementation, or when a required option-argument is not provided, standard utilities shall issue a diagnostic message to standard error and exit with an exit status that indicates an error occurred.
All utilities in this volume of POSIX.1-2024 shall be capable of processing arguments using eight-bit transparency.
Default Behavior: When this section is listed as "None.", it means that the implementation need not support any options. Standard utilities that do not accept options, but that do accept operands, shall recognize "--" as a first argument to be discarded.
The requirement for recognizing "--" is because conforming applications need a way to shield their operands from any arbitrary options that the implementation may provide as an extension. For example, if the standard utility foo is listed as taking no options, and the application needed to give it a pathname with a leading <hyphen-minus>, it could safely do it as:
foo -- -myfile
and avoid any problems with -m used as an extension.
If an operand naming a file can be specified as '-', which means to use the standard input instead of a named file, this is explicitly stated in this section. Unless otherwise stated, the use of multiple instances of '-' to mean standard input in a single command produces unspecified results.
Unless otherwise stated, the standard utilities that accept operands shall process those operands in the order specified in the command line.
Default Behavior: When this section is listed as "None.", it means that the implementation need not support any operands.
Use of a terminal for standard input can cause any of the standard utilities that read standard input to stop when used in the background. For this reason, applications should not use interactive features in scripts to be placed in the background.
The specified standard input format of the standard utilities shall not depend on the existence or value of the environment variables defined in this volume of POSIX.1-2024, except as provided by this volume of POSIX.1-2024.
Default Behavior: When this section is listed as "Not used.", it means that the standard input shall not be read when the utility is used as described by this volume of POSIX.1-2024.
All utilities in this volume of POSIX.1-2024 shall be capable of processing input files using eight-bit transparency.
When a standard utility reads a seekable input file and terminates without an error before it reaches end-of-file, the utility shall ensure that the file offset in the open file description is properly positioned just past the last byte processed by the utility. For files that are not seekable, the state of the file offset in the open file description for that file is unspecified. A conforming application shall not assume that the following three commands are equivalent:
tail -n +2 file (sed -n 1q; cat) < file cat file | (sed -n 1q; cat)
The second command is equivalent to the first only when the file is seekable. The third command leaves the file offset in the open file description in an unspecified state. Other utilities, such as head, read, and sh, have similar properties.
Some of the standard utilities, such as filters, process input files a line or a block at a time and have no restrictions on the maximum input file size. Some utilities may have size limitations that are not as obvious as file space or memory limitations. Such limitations should reflect resource limitations of some sort, not arbitrary limits set by implementors. Implementations shall document those utilities that are limited by constraints other than file system space, available memory, and other limits specifically cited by this volume of POSIX.1-2024, and identify what the constraint is and indicate a way of estimating when the constraint would be reached. Similarly, some utilities descend the directory tree (recursively). Implementations shall also document any limits that they may have in descending the directory tree that are beyond limits cited by this volume of POSIX.1-2024.
When an input file is described as a "text file", the utility produces undefined results if given input that is not from a text file, unless otherwise stated. Some utilities (for example, make, read, sh) allow for continued input lines using an escaped <newline> convention; unless otherwise stated, the utility need not be able to accumulate more than {LINE_MAX} bytes from a set of multiple, continued input lines. Thus, for a conforming application the total of all the continued lines in a set cannot exceed {LINE_MAX}. If a utility using the escaped <newline> convention detects an end-of-file condition immediately after an escaped <newline>, the results are unspecified.
Record formats are described in a notation similar to that used by the C-language function, printf(). See XBD 5. File Format Notation for a description of this notation. The format description is intended to be sufficiently rigorous to allow other applications to generate these input files. However, since <blank>s can legitimately be included in some of the fields described by the standard utilities, particularly in locales other than the POSIX locale, this intent is not always realized.
Default Behavior: When this section is listed as "None.", it means that no input files are required to be supplied when the utility is used as described by this volume of POSIX.1-2024.
The entire manner in which environment variables described in this volume of POSIX.1-2024 affect the behavior of
each utility is described in the ENVIRONMENT VARIABLES section for that utility, in conjunction with the global effects of the
LANG , LC_ALL , and [XSI] NLSPATH
environment
variables described in XBD 8. Environment Variables . The existence or value
of environment variables described in this volume of POSIX.1-2024 shall not otherwise affect the specified behavior of the standard
utilities. Any effects of the existence or value of environment variables not described by this volume of POSIX.1-2024 upon the
standard utilities are unspecified.
For those standard utilities that use environment variables as a means for selecting a utility to execute (such as CC in make), the string provided to the utility is subjected to the path search described for PATH in XBD 8. Environment Variables .
All utilities in this volume of POSIX.1-2024 shall be capable of processing environment variable names and values using eight-bit transparency.
Default Behavior: When this section is listed as "None.", it means that the behavior of the utility is not directly affected by environment variables described by this volume of POSIX.1-2024 when the utility is used as described by this volume of POSIX.1-2024.
Default Behavior: When this section is listed as "Default.", or it refers to "the standard action" for any signal, it means that the action taken as a result of the signal shall be as follows:
When the required action is for the signal to terminate the utility, the utility may catch the signal, perform some additional processing (such as deleting temporary files), restore the default signal action, and resignal itself.
Use of a terminal for standard output may cause any of the standard utilities that write standard output to stop when used in the background. For this reason, applications should not use interactive features in scripts to be placed in the background.
Record formats are described in a notation similar to that used by the C-language function, printf(). See XBD 5. File Format Notation for a description of this notation.
The specified standard output of the standard utilities shall not depend on the existence or value of the environment variables defined in this volume of POSIX.1-2024, except as provided by this volume of POSIX.1-2024.
Some of the standard utilities describe their output using the verb display, defined in XBD 3.107 Display . Output described in the STDOUT sections of such utilities may be produced using means other than standard output. When standard output is directed to a terminal, the output described shall be written directly to the terminal. Otherwise, the results are undefined.
Default Behavior: When this section is listed as "Not used.", it means that the standard output shall not be written when the utility is used as described by this volume of POSIX.1-2024.
Use of a terminal for standard error may cause any of the standard utilities that write standard error output to stop when used in the background. For this reason, applications should not use interactive features in scripts to be placed in the background.
The format of diagnostic messages for most utilities is unspecified, but the language and cultural conventions of
diagnostic and informative messages whose format is unspecified by this volume of POSIX.1-2024 should be affected by the setting of
LC_MESSAGES and [XSI] NLSPATH .
The specified standard error output of standard utilities shall not depend on the existence or value of the environment variables defined in this volume of POSIX.1-2024, except as provided by this volume of POSIX.1-2024.
Default Behavior: When this section is listed as "The standard error shall be used only for diagnostic messages.", it means that, unless otherwise stated, the diagnostic messages shall be sent to the standard error only when the exit status indicates that an error occurred and the utility is used as described by this volume of POSIX.1-2024.
When this section is listed as "Not used.", it means that the standard error shall not be used when the utility is used as described in this volume of POSIX.1-2024.
Implementations shall ensure that temporary files, when used by the standard utilities, are named so that different utilities or multiple instances of the same utility can operate simultaneously without regard to their working directories, or any other process characteristic other than process ID. There are two exceptions to this rule:
Any temporary file created by the implementation shall be removed by the implementation upon a utility's successful exit, exit because of errors, or before termination by any of the SIGHUP, SIGINT, or SIGTERM signals, unless specified otherwise by the utility description.
Receipt of the SIGQUIT signal should generally cause termination (unless in some debugging mode) that would bypass any attempted recovery actions.
Record formats are described in a notation similar to that used by the C-language function, printf(); see XBD 5. File Format Notation for a description of this notation.
Default Behavior: When this section is listed as "None.", it means that no files are created or modified as a consequence of direct action on the part of the utility when the utility is used as described by this volume of POSIX.1-2024. However, the utility may create or modify system files, such as log files, that are outside the utility's normal execution environment.
Default Behavior: When this section is listed as "None.", no further description is necessary.
For example, a utility may list zero as a successful return, 1 as a failure for a specific reason, and >1 as "an error occurred". In this case, unspecified conditions may cause a 2 or 3, or other value, to be returned. A conforming application should be written so that it tests for successful exit status values (zero in this case), rather than relying upon the single specific error value listed in this volume of POSIX.1-2024. In that way, it has maximum portability, even on implementations with extensions.
Unspecified error conditions may be represented by specific values not listed in this volume of POSIX.1-2024.
Default Behavior: When the description of exit status 0 is "Successful completion", it means that exit status 0 shall indicate that all of the actions the utility is required to perform were completed successfully.
The many reasons for failure of a utility are generally not specified by the utility descriptions. Utilities may terminate prematurely if they encounter: invalid usage of options, arguments, or environment variables; invalid usage of the complex syntaxes expressed in EXTENDED DESCRIPTION sections; resource exhaustion; difficulties accessing, creating, reading, or writing files; or difficulties associated with the privileges of the process.
The following shall apply to each utility, unless otherwise stated:
For a utility that recursively traverses a file hierarchy (such as find
or chown -R), if the requested action cannot be performed on a file or
directory encountered in the hierarchy, the utility shall issue a diagnostic message to standard error and continue processing the
remaining files in the hierarchy, but the final exit status shall be one that indicates an error occurred.
When a utility encounters an error condition several actions are possible, depending on the severity of the error and the state of the utility. Included in the possible actions of various utilities are: deletion of temporary or intermediate work files; deletion of incomplete files; validity checking of the file system or directory.
Default Behavior: When this section is listed as "Default.", it means that any changes to the environment, file systems, process state, and so on are unspecified.
The APPLICATION USAGE section gives advice to the application programmer or user about the way the utility should be used.
The EXAMPLES section gives one or more examples of usage, where appropriate. In the event of conflict between an example and a normative part of the specification, the normative material is to be taken as correct.
In all examples, quoting has been used, showing how sample commands (utility names combined with arguments) could be passed correctly to a shell (see sh) or as a string to the system() function defined in the System Interfaces volume of POSIX.1-2024. Such quoting would not be used if the utility is invoked using one of the exec functions defined in the System Interfaces volume of POSIX.1-2024.
This section contains historical information concerning the contents of this volume of POSIX.1-2024 and why features were included or discarded by the standard developers.
The FUTURE DIRECTIONS section should be used as a guide to current thinking; there is not necessarily a commitment to implement all of these future directions in their entirety.
The SEE ALSO section lists related entries.
This section shows the derivation of the entry and any significant changes that have been made to it.
Certain of the standard utilities describe how they can invoke other utilities or applications, such as by passing a command string to the command interpreter. The external influences (STDIN, ENVIRONMENT VARIABLES, and so on) and external effects (STDOUT, CONSEQUENCES OF ERRORS, and so on) of such invoked utilities are not described in the section concerning the standard utility that invokes them.
The following utilities support files of any size up to the maximum that can be created by the implementation. This support includes correct writing of file size-related values (such as file sizes and offsets, line numbers, and block counts) and correct interpretation of command line arguments that contain such values.
Exceptions to the requirement that utilities support files of any size up to the maximum are as follows:
Any of the standard utilities may be implemented as regular built-in utilities within the command language interpreter. This is usually done to increase the performance of frequently used utilities or to achieve functionality that would be more difficult in a separate environment. The intrinsic utilities described in 1.7 Intrinsic Utilities below are frequently provided as regular built-ins.
However, all of the standard utilities other than:
shall be implemented, regardless of whether they are also implemented as regular built-ins, in a manner so that they can be accessed via the exec family of functions as defined in the System Interfaces volume of POSIX.1-2024 and can be invoked directly by those standard utilities that require it (env, find, nice, nohup, time, xargs).
As described in 2.9.1.4 Command Search and
Execution , intrinsic utilities are not subject to a PATH search during command search and execution. The utilities
named in Intrinsic Utilities shall be intrinsic utilities.
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 Intrinsic Utilities .
return to top of page