NAME

dirname — return the directory portion of a pathname

SYNOPSIS

dirname string

DESCRIPTION

The string operand shall be treated as a pathname, as defined in XBD 3.254 Pathname , 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.

OPTIONS

None.

OPERANDS

The following operand shall be supported:

string
A string.

STDIN

Not used.

INPUT FILES

None.

ENVIRONMENT VARIABLES

The following environment variables shall affect the execution of dirname:

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
If set to a non-empty string value, override the values of all the other internationalization variables.
LC_CTYPE
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).
LC_MESSAGES

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

ASYNCHRONOUS EVENTS

Default.

STDOUT

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

"%s\n", <resulting string>

STDERR

The standard error shall be used only for diagnostic messages.

OUTPUT FILES

None.

EXTENDED DESCRIPTION

None.

EXIT STATUS

The following exit values shall be returned:

 0
Successful completion.
>0
An error occurred.

CONSEQUENCES OF ERRORS

Default.


The following sections are informative.

APPLICATION USAGE

The definition of pathname 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.

EXAMPLES

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

See also the examples for the basename utility.

RATIONALE

The behaviors of basename 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 3.254 Pathname allows trailing <slash> characters. The basename and dirname utilities have to specify consistent handling for all valid pathnames.

The dirname utility is not specified in terms of the dirname() 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 "//".

FUTURE DIRECTIONS

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.

SEE ALSO

2.5 Parameters and Variables , basename

XBD 3.254 Pathname , 8. Environment Variables

XSH basename , dirname

CHANGE HISTORY

First released in Issue 2.

Issue 7

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.

Issue 8

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() function.

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

End of informative text.