sort [-m] [-o output] [-bdfinru] [-t char] [-k keydef]... [file...] sort [-c|-C] [-bdfinru] [-t char] [-k keydef] [file]
Comparisons shall be based on one or more sort keys extracted from each line of input (or, if no sort keys are specified, the entire line up to, but not including, the terminating <newline>), and shall be performed using the collating sequence of the current locale. If this collating sequence does not have a total ordering of all characters (see the Base Definitions volume of POSIX.1-2017, Section 7.3.2, LC_COLLATE), any lines of input that collate equally should be further compared byte-by-byte using the collating sequence for the POSIX locale.
The following options shall be supported:
The following options shall override the default ordering rules. When ordering options appear independent of any key field specifications, the requested field ordering rules shall be applied globally to all sort keys. When attached to a specific key (see -k), the specified ordering options shall override all global ordering options for that key.
The treatment of field separators can be altered using the options:
Sort keys can be specified using the options:
field_start[type][,field_end[type]]
where field_start and field_end define a key field restricted to a portion of the line (see the EXTENDED DESCRIPTION section), and type is one or more modifiers from the list of characters 'b', 'd', 'f', 'i', 'n', 'r'. The 'b' modifier shall behave like the -b option, but shall apply only to the field_start or field_end to which it is attached. The other modifiers shall behave like the corresponding options, but shall apply only to the key field to which they are attached; they shall have this effect if specified with field_start, field_end, or both. If any modifier is attached to a field_start or to a field_end, no option shall apply to either. Implementations shall support at least nine occurrences of the -k option, which shall be significant in command line order. If no -k option is specified, a default sort key of the entire line shall be used.
When there are multiple key fields, later keys shall be compared only after all earlier keys compare equal. Except when the -u option is specified, lines that otherwise compare equal shall be ordered as if none of the options -d, -f, -i, -n, or -k were present (but with -r still in effect, if it was specified) and with all bytes in the lines significant to the comparison. The order in which lines that still compare equal are written is unspecified.
-k field_start[type][,field_end[type]]
shall define a key field that begins at field_start and ends at field_end inclusive, unless field_start falls beyond the end of the line or after field_end, in which case the key field is empty. A missing field_end shall mean the last character of the line.
A field comprises a maximal sequence of non-separating characters and, in the absence of option -t, any preceding field separator.
The field_start portion of the keydef option-argument shall have the form:
field_number[.first_character]
Fields and characters within fields shall be numbered starting with 1. The field_number and first_character pieces, interpreted as positive decimal integers, shall specify the first character to be used as part of a sort key. If .first_character is omitted, it shall refer to the first character of the field.
The field_end portion of the keydef option-argument shall have the form:
field_number[.last_character]
The field_number shall be as described above for field_start. The last_character piece, interpreted as a non-negative decimal integer, shall specify the last character to be used as part of the sort key. If last_character evaluates to zero or .last_character is omitted, it shall refer to the last character of the field specified by field_number.
If the -b option or b type modifier is in effect, characters within a field shall be counted from the first non-<blank> in the field. (This shall apply separately to first_character and last_character.)
The following sections are informative.
<space><space>foo
the following treatment would occur with default separation as opposed to specifically selecting a <space>:
| |||||||||||||||
The leading field separator itself is included in a field when -t is not used. For example, this command returns an exit status of zero, meaning the input was already sorted:
sort -c -k 2 <<eof y<tab>b x<space>a eof
(assuming that a <tab> precedes the <space> in the current collating sequence). The field separator is not included in a field when it is explicitly set via -t. This is historical practice and allows usage such as:
sort -t "|" -k 2n <<eof Atlanta|425022|Georgia Birmingham|284413|Alabama Columbia|100385|South Carolina eof
where the second field can be correctly sorted numerically without regard to the non-numeric field separator.
The wording in the OPTIONS section clarifies that the -b, -d, -f, -i, -n, and -r options have to come before the first sort key specified if they are intended to apply to all specified keys. The way it is described in this volume of POSIX.1-2017 matches historical practice, not historical documentation. The results are unspecified if these options are specified after a -k option.
The -f option might not work as expected in locales where there is not a one-to-one mapping between an uppercase and a lowercase letter.
When using sort to process pathnames, it is recommended that LC_ALL, or at least LC_CTYPE and LC_COLLATE, are set to POSIX or C in the environment, since pathnames can contain byte sequences that do not form valid characters in some locales, in which case the utility's behavior would be undefined. In the POSIX locale each byte is a valid single-byte character, and therefore this problem is avoided.
If the collating sequence of the current locale does not have a total ordering of all characters, this can affect the behavior of sort in the following ways:
sort -k 2,2 infile
sort -r -o outfile -k 2.2,2.2 infile1 infile2
sort -k 2.2b,2.2b infile1 infile2
sort -t : -k 3,3n /etc/passwd
sort -um -k 3.1,3.0 infile
The -z option was omitted; it is not standard practice on most systems and is inconsistent with using sort to sort several files individually and then merge them together. The text concerning -z in historical documentation appeared to require implementations to determine the proper buffer length during the sort phase of operation, but not during the merge.
The -y option was omitted because of non-portability. The -M option, present in System V, was omitted because of non-portability in international usage.
An undocumented -T option exists in some implementations. It is used to specify a directory for intermediate files. Implementations are encouraged to support the use of the TMPDIR environment variable instead of adding an option to support this functionality.
The -k option was added to satisfy two objections. First, the zero-based counting used by sort is not consistent with other utility conventions. Second, it did not meet syntax guideline requirements.
Historical documentation indicates that ``setting -n implies -b''. The description of -n already states that optional leading <blank>s are tolerated in doing the comparison. If -b is enabled, rather than implied, by -n, this has unusual side-effects. When a character offset is used in a column of numbers (for example, to sort modulo 100), that offset is measured relative to the most significant digit, not to the column. Based upon a recommendation from the author of the original sort utility, the -b implication has been omitted from this volume of POSIX.1-2017, and an application wishing to achieve the previously mentioned side-effects has to code the -b flag explicitly.
Earlier versions of this standard allowed the -o option to appear after operands. Historical practice allowed all options to be interspersed with operands. This version of the standard allows implementations to accept options after operands but conforming applications should not use this form.
Earlier versions of this standard also allowed the -number and +number options. These options are no longer specified by POSIX.1-2008 but may be present in some implementations.
Historical implementations produced a message on standard error when -c was specified and disorder was detected, and when -c and -u were specified and a duplicate key was detected. An earlier version of this standard contained wording that did not make it clear that this message was allowed and some implementations removed this message to be sure that they conformed to the standard's requirements. Confronted with this difference in behavior, interactive users that wanted to be sure that they got visual feedback instead of just exit code 1 could have used a command like:
sort -c file || echo disorder
whether or not the sort utility provided a message in this case. But, it was not easy for a user to find where the disorder or duplicate key occurred on implementations that do not produce a message, especially when some parts of the input line were not part of the key and when one or more of the -b, -d, -f, -i, -n, or -r options or keydef type modifiers were in use. POSIX.1-2008 requires a message to be produced in this case. POSIX.1-2008 also contains the -C option giving users the ability to choose either behavior.
When a disorder or duplicate is found when the -c option is specified, some implementations print a message containing the first line that is out of order or contains a duplicate key; others print a message specifying the line number of the offending line. This standard allows either type of message.
Implementations are encouraged to perform the recommended further byte-by-byte comparison of lines that collate equally, even though this may affect efficiency. The impact on efficiency can be mitigated by only performing the additional comparison if the current locale's collating sequence does not have a total ordering of all characters (if the implementation provides a way to query this) or by only performing the additional comparison if the locale name associated with the LC_COLLATE category has an '@' modifier in the name (since locales without an '@' modifier should have a total ordering of all characters --- see the Base Definitions volume of POSIX.1-2017, Section 7.3.2, LC_COLLATE). Note that if the implementation provides a stable sort option as an extension (usually -s), the additional comparison should not be performed when this option has been specified.
The Base Definitions volume of POSIX.1-2017, Section 7.3.2, LC_COLLATE, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines
The System Interfaces volume of POSIX.1-2017, toupper()
Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .