SORT(1) General Commands Manual SORT(1)

sort — sort, merge, or sequence check text files

sort [−m] [−o output] [−bdfinru] [−t char] [−k keydef] . . . [file . . . ]
sort −c [−bdfinru] [−t char] [−k keydef] . . . [file]
Obsolescent Versions:
sort [−mu] [−o output] [−bdfinr] [−t char] [+pos1[−pos2]] . . . [file . . . ]
sort −c [−u] [−bdfinr] [−t char] [+pos1[−pos2]] . . . [file]

The sort utility shall perform one of the following functions:

  1. Sort lines of all the named files together and write the result to the specified output.
  2. Merge lines of all the named (presorted) files together and write the result to the specified output.
  1. Check that a single input file is correctly presorted.

Comparisons shall be based on one or more sort keys extracted from each line of input (or the entire line if no sort keys are specified), and shall be performed using the collating sequence of the current locale.

The sort utility shall conform to the utility argument syntax guidelines described in 2.10.2, except that the notation +pos1 −pos2 uses a nonstandard prefix and multidigit option names in the obsolescent versions, the −o output option shall be recognized after a file operand as an obsolescent feature in both versions where the −c option is not specified, and the −k keydef option should follow the −b, −d, −f, −i, −n, and −r options. The following options shall be supported by the implementation:

Check that the single input file is ordered as specified by the arguments and the collating sequence of the current locale. No output shall be produced; only the exit code shall be affected.

Merge only; the input files shall be assumed to be already sorted.

output

Specify the name of an output file to be used instead of the standard output. This file can be the same as one of the input files.

Unique: suppress all but one in each set of lines having equal keys. If used with the −c option, check that there are no lines with duplicate keys, in addition to checking that the input file is sorted. 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. In the obsolescent forms, if one or more of these options follows a +pos1 option, it shall affect only the key field specified by that preceding option.

Specify that only <blank>s and alphanumeric characters, according to the current setting of LC_CTYPE, shall be significant in comparisons. The behavior is undefined for a sort key to which

or −n also applies.

Consider all lowercase characters that have uppercase equivalents, according to the current setting of LC_CTYPE, to be the uppercase equivalent for the purposes of comparison.

Ignore all characters that are nonprintable, according to the current setting of LC_CTYPE.

Restrict the sort key to an initial numeric string, consisting of optional <blank>s, optional minus sign, and zero or more digits with an optional radix character and thousands separators (as defined in the current locale), which shall be sorted by arithmetic value. An empty digit string shall be treated as zero. Leading zeros and signs on zeros shall not affect ordering.

Reverse the sense of comparisons. The treatment of field separators can be altered using the options:

Ignore leading <blank>s when determining the starting and ending positions of a restricted sort key. If the −b option is specified before the first −k option, it shall be applied to all −k options. Otherwise, the −b option can be attached independently to each

field_start or field_end option-argument (see below).

char

Use char as the field separator character; char shall not be considered to be part of a field (although it can be included in a sort key). Each occurrence of char shall be significant (for example, <char><char> shall delimit an empty field). If −t is not specified, <blank> characters shall be used as default field separators; each maximal nonempty sequence of <blank> characters that follows a non-<blank> character shall be a field separator. Sort keys can be specified using the options:

keydef

The keydef argument is a restricted sort key field definition. The format of this definition is field_start[type][,field_end[type]] where field_start and field_end define a key field restricted to a portion of the line (see EXTENDED DESCRIPTION ), and type is a modifier from the list of characters b, d, f, i, n, r. The b modifier shall behave like the

option, but applies 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. Modifiers attached to a field_start or field_end shall override any specifications made by the options. 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.

+pos1 (Obsolescent.) Specify the start position of a key field. See EXTENDED DESCRIPTION . −pos2 (Obsolescent.) Specify the end position of a key field. See EXTENDED DESCRIPTION .

The following operand shall be supported by the implementation:

file

A pathname of a file to be sorted, merged, or checked. If no file operands are specified, or if a file operand is −, the standard input shall be used.

The standard input shall be used only if no file operands are specified, or if a file operand is −. See Input Files.

The input files shall be text files, except that the sort utility shall add a <newline> to the end of a file ending with an incomplete last line.

The following environment variables shall affect the execution of sort:

This variable shall determine the locale to use for the locale categories when both LC_ALL and the corresponding environment variable (beginning with LC_ ) do not specify a locale. See 2.6.

This variable shall determine the locale to be used to override any values for locale categories specified by the settings of LANG or any environment variables beginning with LC_.

This variable shall determine the locale for ordering rules.

This variable shall determine the locale for the interpretation of sequences of bytes of text data as characters (e.g., single- versus multibyte characters in arguments and input files) and the behavior of character classification for the −b, −d, −f, −i, and −n options.

This variable shall determine the language in which messages should be written.

This variable shall determine the locale for the definition of the radix character and thousands separator for the −n option.

Default.

Unless the −o or −c options are in effect, the standard output shall contain the sorted input.

Used only for diagnostic messages. A warning message about correcting an incomplete last line of an input file may be generated, but need not affect the final exit status.

If the −o option is in effect, the sorted input shall be placed in the file output.

The notation −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 shall be empty. A missing field_end shall mean the last character of the line. A field comprises a maximal sequence of nonseparating 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 nonnegative 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 obsolescent [ +pos1 [−pos2] ] options provide functionality equivalent to the −k keydef option. For comparison, the full formats of these options shall be: +field0_number[.first0_character][type] [−field0_number[.first0_character][type]] -k field_number[.first_character][type][,field_number[.last_character][type]] In the obsolescent form, fields (specified by field0_number) and characters within fields (specified by first0_character) shall be numbered from zero instead of one. The −pos2 option shall specify the first character after the sort field instead of the last character in the sort field. (Therefore, field0_number and first0_character shall be interpreted as nonnegative, instead of positive, decimal integers and there is no need for a specification of a last_character-like form.) The optional type modifiers shall be the same in both forms. If .first0_character is omitted or first0_character evaluates to zero, it shall refer to the first character of the field. Thus, a the fully specified +pos1 −pos2 form: +w.x -y.z shall be equivalent to: -k w+1.x+1,y.0 (if z == 0) -k w+1.x+1,y+1.z (if z > 0) As with the nonobsolescent forms, implementations shall support at least nine occurrences of the +pos1 option, which shall be significant in command line order.

The sort utility shall exit with one of the following values:

All input files were output successfully, or −c was specified and the input file was correctly sorted.

Under the −c option, the file was not ordered as specified, or if the −c and −u options were both specified, two input lines were found with equal keys. This exit status shall not be returned if the −c option is not used.

An error occurred.

Default.

In the following examples, nonobsolescent and obsolescent ways of specifying sort keys are given as an aid to understanding the relationship between the two forms. Either of the following commands sorts the contents of infile with the second field as the sort key: sort -k 2,2 infile sort +1 -2 infile Either of the following commands sorts, in reverse order, the contents of infile1 and infile2, placing the output in outfile and using the second character of the second field as the sort key (assuming that the first character of the second field is the field separator): sort -r -o outfile -k 2.2,2.2 infile1 infile2 sort -r -o outfile +1.1 -1.2 infile1 infile2 Either of the following commands sorts the contents of infile1 and infile2 using the second non-<blank> character of the second field as the sort key: sort -k 2.2b,2.2b infile1 infile2 sort +1.1b -1.2b infile1 infile2 Either of the following commands prints the System V password file (user database) sorted by the numeric user ID (the third colon-separated field): sort -t : -k 3,3n /etc/passwd sort -t : +2 -3n /etc/passwd Either of the following commands prints the lines of the already sorted file infile, suppressing all but one occurrence of lines having the same third field: sort -um -k 3.1,3.0 infile sort -um +2.0 -3.0 infile Examples in some historical documentation state that options −um with one input file keep the first in each set of lines with equal keys. This behavior was deemed to be an implementation artifact and was not made standard.

The default value for −t, <blank>, has different properties than, for example, -t "<space>". If a line contains: <space><space>foo the following treatment would occur with default separation versus specifically selecting a <space>:

Field

Default -t

"<space>" 1 <space><space>foo empty 2 empty empty 3 empty foo

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 <tab> precedes <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 nonnumeric field separator.

The −z option was removed; it is not standard practice on most systems, and is inconsistent with using sort to individually sort several files and then merging them together. The previous language 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 removed because of nonportability. The −M option, present in System V, was removed because of nonportability 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 environment variable instead of adding an option to support this functionality. The −k option was added to satisfy two complaints. First, the zero-based counting used by sort is not consistent with other utility conventions. Second, it did not meet syntax guideline requirements. The one-based counting in this standard was developed from the input provided by several ballot comments, ballot objections, and discussions with users. The wording in Draft 10 also 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 standard matches historical practice, not historical documentation. In the nonobsolescent versions, the results are

unspecified if these options are specified after a −k option. This will allow implementations to make the options independent of each other when the obsolescent forms are finally dropped (if that ever happens). 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 into a column of numbers (e.g., to sort mod 100), that offset will be measured relative to the most significant digit, not to the column. Based upon a recommendation of the author of the original sort utility, the −b implication has been omitted from . 2 and an application wishing to achieve the previously mentioned side effects will have to manually code the −b flag.

September 1991 posix.fail