DIRNAME(1) General Commands Manual DIRNAME(1)

dirname — return the directory portion of a pathname

dirname string

The string operand shall be treated as a pathname, as defined in XBD V1_chap03(7), and shall be converted to a pathname of the directory containing the entry of the final pathname component. The resulting string shall be written to standard output. The dirname utility shall not perform pathname resolution; the result shall not be affected by whether or not a file with the pathname string exists or by its file type. Trailing ‘/’ characters in string that are not also leading ‘/’ characters shall not be counted as part of the pathname. If the pathname does not contain a ‘/’, the resulting string shall be ".". If string is an empty string, the resulting string shall be ".".

It is unspecified whether redundant ‘/’ characters and ‘’. pathname components in string are removed after determining the pathname to output. However, ".." pathname components occurring prior to the final component shall not be removed.

None.

The following operand shall be supported:

string
A string.

Not used.

None.

The following environment variables shall affect the execution of dirname:

Provide a default value for the internationalization variables that are unset or null. (See XBD for the precedence of internationalization variables used to determine the values of locale categories.)
If set to a non-empty string value, override the values of all the other internationalization variables.
Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments).

Determine the locale that should be used to affect the format and contents of diagnostic messages written to standard error.
[ XSI] Determine the location of messages objects and message catalogs.

Default.

The dirname utility shall write a line to the standard output in the following format:

"%s\n", <resulting string>

The standard error shall be used only for diagnostic messages.

None.

None.

The following exit values shall be returned:

Successful completion.
An error occurred.

Default.

The definition of specifies implementation-defined behavior for pathnames starting with two <slash> characters. Therefore, applications shall not arbitrarily add <slash> characters to the beginning of a pathname unless they can ensure that there are more or less than two or are prepared to deal with the implementation-defined consequences.

The EXAMPLES section of the basename(3) function (see XSH basename(3)) includes a table showing examples of the results of processing several sample pathnames by the basename(3) and dirname(3) functions and by the basename(1) and dirname utilities.

See also the examples for the basename(1) utility.

The behaviors of basename(1) and dirname in this volume of POSIX.1-2024 have been coordinated so that when string is a valid pathname:

$(basename -- "string")

would be a valid filename for the file in the directory:

$(dirname -- "string")

This would not work for the versions of these utilities in early proposals due to the way processing of trailing <slash> characters was specified. Consideration was given to leaving processing unspecified if there were trailing <slash> characters, but this cannot be done; XBD V1_chap03(7) allows trailing <slash> characters. The basename(1) and dirname utilities have to specify consistent handling for all valid pathnames.

The dirname utility is not specified in terms of the dirname(3) function, because the two may produce slightly different output where both output forms are still compliant. An implementation should prefer the shortest output possible; however, this is not required, in part because earlier versions of the standard did not permit elision of redundant <slash> characters or dot ( ‘’.) components. Removal of the dot-dot ( "..") pathname component is not permitted, because eliding it correctly would require performing pathname resolution to ensure the resulting string would still point to the correct pathname if the original string resolved as a pathname. On implementations where pathname "//" has an implementation-defined meaning distinct from the pathname "/", the dirname of "//" will be "//".

If this utility is directed to display a pathname that contains any bytes that have the encoded value of a <newline> character when <newline> is a terminator or separator in the output format being used, implementations are encouraged to treat this as an error. A future version of this standard may require implementations to treat this as an error.

2.5 Parameters and Variables, basename(1)

XBD V1_chap03(7), V1_chap08(7)

XSH basename(3), dirname(3)

First released in Issue 2.

POSIX.1-2008, Technical Corrigendum 1, XCU/TC1-2008/0083 [192,430], XCU/TC1-2008/0084 [192], and XCU/TC1-2008/0085 [192] are applied.

POSIX.1-2008, Technical Corrigendum 2, XCU/TC2-2008/0086 [612], XCU/TC2-2008/0087 [620], and XCU/TC2-2008/0088 [612] are applied.

Austin Group Defect 251 is applied, encouraging implementations to report an error if a utility is directed to display a pathname that contains any bytes that have the encoded value of a <newline> character when <newline> is a terminator or separator in the output format being used.

Austin Group Defect 1073 is applied, replacing the DESCRIPTION section with one that matches the dirname(3) function.

Austin Group Defect 1122 is applied, changing the description of NLSPATH .

June 14, 2024 posix.fail