34

For a long period I thought the default behavior of the sort program was using ASCII order. However, when I input the following lines into sort without any arguments:

#
@

I got:

@
#

But according to the ASCII table, # is 35 and @ is 64. Another example is:

A
a

And the output is:

a
A

Can anybody explain this? By the way, what is 'dictionary-order' when using sort -d?

Improve this question
4
  • 5
    sort order depends on your locale settings Commented Jul 19, 2012 at 6:20
  • 2
    But it is alphabetical order by default at least in GNU sort. Commented Jun 25, 2017 at 8:38
  • 2
    Nobody answered the question what the default sort order is. Man page does not mention "alphabetical order", only dictionary-order. However, no mention if that is the default, and no description what that precisely is. Commented Dec 5, 2021 at 13:43
  • @AxelBregnsbo well, I added an answer. Commented Apr 8 at 14:44

4 Answers 4

Reset to default
31

Looks like you are using a non-POSIX locale.

Try:

export LC_ALL=C

and then sort.

info sort clearly says:

(1) If you use a non-POSIX locale (e.g., by setting `LC_ALL' to `en_US'), then `sort' may produce output that is sorted differently than you're accustomed to. In that case, set the `LC_ALL' environment variable to `C'. Note that setting only `LC_COLLATE' has two problems. First, it is ineffective if `LC_ALL' is also set. Second, it has undefined behavior if `LC_CTYPE' (or `LANG', if `LC_CTYPE' is unset) is set to an incompatible value. For example, you get undefined behavior if `LC_CTYPE' is `ja_JP.PCK' but `LC_COLLATE' is `en_US.UTF-8'.

Improve this answer
2
  • 8
    The OP is asking what the sort order is, not how to change it. Commented Jul 19, 2012 at 6:25
  • 1
    Thanks, I've tested on my machine and locale settings do affect sort behavior Commented Jul 19, 2012 at 8:01
6

As man sort says, “dictionary-order” means “consider only blanks and alphanumeric characters”.  For example, given the data

The
!quick
brown
@fox
jumps
#over
17
$lazy
  dogs
%42
times.

the unadorned sort command produces

  dogs
!quick
#over
$lazy
%42
@fox
17
brown
jumps
The
times.

(putting the lines that begin with the space characters and the !, #, $, %, and @ symbols1 ahead of the lines that begin with letters and numbers; i.e., alphanumeric characters), but sort -d produces

  dogs
17
%42
brown
@fox
jumps
$lazy
#over
!quick
The
times.

  dogs is still first, because it begins with spaces, but the special (punctuation) characters are ignored.  17 comes before 42, and fox comes between brown and jumps, in spite of the fact that 42 and fox have characters in front of them that would normally move them before the 17.
____________
1 in order of their ASCII values: space=040, !=041, #=043, $=044, %=045, and @=0100.  Note that (disregarding the space bar) this is approximately left-to-right order on some keyboards.

Improve this answer
1
  • 2
    The order in your first example, where text is sorted first on punctuation, may result if the locale in effect is C (as with LC_ALL=C) but not in other locales. Which locale is the default depends on the OS settings. So, an unadorned sort should be different in many Distributions. Commented Dec 27, 2019 at 23:48
2

To determine the sort order, simply create a file with a different character on each line and the sort it. The resulting output will tell you the sort order.

Improve this answer
3
  • Nice, simple and efficient Commented Jul 19, 2012 at 8:01
  • 2
    Generally a very good idea, but it is not always enough. A collation need not be defined only on individual characters. Some collations treat "ae" as if it were a ligature, or treat ligatures as if they were decomposed. Another case is that many collations treat 'a' and 'A' as equal, but the order you see by testing doesn't tell you that (it may tell you whether the sort is stable). And a single-character test doesn't tell if tab expansion, whitespace normalization, etc. are in effect. Nevertheless, it's a very good place to start. Commented Dec 15, 2017 at 17:48
  • 1
    (too late to edit previous comment) -- so long as you actually include a diverse enough range of characters, you can tell case-ignoring from seeing (for example) aAbB instead of abAB. Commented Dec 15, 2017 at 18:11
0

For POSIX compliant sort implementations applies:

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 XBD 7.3.2 LC_COLLATE), any lines of input that collate equally shall be further compared byte-by-byte using the collating sequence for the POSIX locale.

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sort.html

Improve this answer

You must log in to answer this question.