При использовании команды ls, какие правила влияют на порядок имен, содержащих числа?

Когда переменная LC_COLLATE изменена, изменяются правила относительно порядка имен, содержащих числа.

LC_COLLATE=С ls -1

abc.zml-1.gz
abc.zml-12.gz
abc.zml-2.gz

В этом случае очевидно, что последовательность определяется последовательностью в таблице ASCII.

Теперь изменим значение переменной LC_COLLATE.

LC_COLLATE=”en_US.UTF-8″
(или zh_CN.utf8 или fr_FR.utf8 как значение)

abc.zml-12.gz
abc.zml-1.gz
abc.zml-2.gz

Здесь три разных значения переменной LC_COLLATE, которые имеют общее, что они относятся к UTF8, дают один и тот же результат.

abc.zml-2.gz идет после abc.zml-1.gz, что понятно.
Почему abc.zml-12.gz идет перед abc.zml-1.gz?

Где я могу прочитать официальные правила относительно порядка, в котором перечисляются файлы?

ls по умолчанию сортирует файлы на основе порядка колlation имени в локали.

На системах GNU или любой системе, использующей GNU libc, исходное определение локалей en_US можно увидеть в $prefix/share/i18n/locales/en_US.

Там, в разделе LC_COLLATE, который определяет порядок слияния, вы увидите:

copy "iso14651_t1"

(сам по себе имеющий copy "iso14651_t1_common").

Основано на (старой версии) таблице 1, найденной в приложении международного стандарта ISO 14651.

Большинство других локалей используют это, это не ограничивается en_US.

Там (см. здесь для одной из недавно выпущенных glibc 2.41, хотя файл не изменялся с 2018 года), вы найдете:

% Third-level weight assignments
[...]
<MIN>
[...]
<CAP>
[...]
% First-level weight assignments
[...]
<S0030> % DIGIT ZERO
<S0031> % DIGIT ONE
<S0032> % DIGIT TWO
[...]
<S0067> % LATIN SMALL LETTER G
[...]
order_start <SPECIAL>;forward;backward;forward;forward,position
[...]
<U002D> IGNORE;IGNORE;IGNORE;<U002D> % HYPHEN-MINUS
<U002E> IGNORE;IGNORE;IGNORE;<U002E> % FULL STOP
[...]
<U0030> <S0030>;<BASE>;<MIN>;<U0030> % DIGIT ZERO
[...]
<U0031> <S0031>;<BASE>;<MIN>;<U0031> % DIGIT ONE
[...]
<U0032> <S0032>;<BASE>;<MIN>;<U0032> % DIGIT TWO
[...]
<U0047> <S0067>;<BASE>;<CAP>;<U0047> % LATIN CAPITAL LETTER G
[...]
<U0067> <S0067>;<BASE>;<MIN>;<U0067> % LATIN SMALL LETTER G

В этом порядке.

Эти последние несколько строк определяют вес для каждого слияющего элемента:

<коллатинг-элемент> <вес1>;<вес2>;<вес3>;<вес4> % комментарий

Вы заметите, что дефис и точка, как и большинство знаков препинания, имеют IGNORE в качестве первичного, вторичного, третичного весов, только четвертый последний резервный определяется, в то время как ASCII десятичные цифры и буквы имеют все они.

При сравнении abc.zml-1.gz с abc.zml-12.gz сравнение будет сначала сделано на основе первичных весов. Поскольку вес - и . равен IGNORE, это будет как сравнение abczml1gz и abczml12gz, и первичный вес 2 идет перед весом g.

Если бы мы сравнивали abc.zml-1.gz и abc.zml-1Gz, все первичные и вторичные веса были бы одинаковыми, поэтому определение будет сделано на основе третичного веса, сравнивая <MIN><MIN><MIN><MIN><MIN><MIN><MIN><MIN><MIN> с <MIN><MIN><MIN><MIN><MIN><MIN><MIN><CAP><MIN> (взяв третичные веса каждого символа, где . и - все еще IGNORE, поэтому удалены), и <MIN> будет идти перед <CAP>, так что то, с маленькой g идет первым.

При сравнении abc.zml-1.gz с abc-zml-1.gz нам пришлось бы подняться до четвертого веса.

Это предназначено для имитации порядка, используемого в локали пользователя, как это делается, например, в словаре, где знаки пунктуации, регистр, диакритики обычно игнорируются в первую очередь, но могут использоваться для уточнения порядка при прочих равных (в этом случае некоторые локали предпочитают нижний регистр перед малым капсом и перед верхним регистром, некоторые делают ударения перед острым ударением…)

В локали C на системах GNU порядок основывается на значении символов. Если LC_CTYPE использует многобайтовое кодирование, такое как (но не ограничиваясь) UTF-8, это будет основываться на кодовой точке Unicode (от U+0000 до U+10FFFF; не все системы делают то же самое). Если нет (включая с LC_ALL=C, что подразумевает LC_CTYPE=C), то на значении байта. Например, € (U+20AC) будет сортироваться после é (U+00E9) с LC_CTYPE=en_US.UTF-8 LC_COLLATE=C, но перед с LC_CTYPE=en_US.is0885915 LC_COLLATE=C, потому что € там закодирован как 0xA4, а é как 0xE9.

$ printf '\u20ac\n\u00e9\n' | iconv -t iso885915 | LC_CTYPE=en_US.iso885915 LC_COLLATE=C sort | iconv -f iso885915
€
é
$ printf '\u20ac\n\u00e9\n' | LC_CTYPE=en_US.UTF-8 LC_COLLATE=C sort
é
€

UTF-8 обладает этим свойством, что его кодировка сортируется по значению байта так же, как его символы по кодовой точке, так что для текста с кодировкой UTF-8 LC_CTYPE=en_US.UTF-8 LC_COLLATE=C и LC_CTYPE=C LC_COLLATE=C (или LC_ALL=C) должны дать один и тот же результат. Последнее также будет гораздо менее ресурсозатратным и лучше работать в условиях неправильно закодированного текста.

Обратите внимание, что реализация ls в GNU имеет -v / --sort=version, который выполняет сортировку версий, а реализация sort в GNU имеет -V/--version-sort, который может помочь ordenar вещи числовым образом. См. также модификатор n глобальной переменной zsh.

Например, в zsh:

print -rC1 -- *.gz(n)

Выведет raw в одном Cолонке список ненаблюдаемых имен файлов, заканчивающихся на .gz numerically (числа сравниваются числово, а остальная часть основывается на порядке слияния).

Добавление 0 ко всем числам до одинаковой ширины обеспечивает сортировку по лексическому и числовому механизмам, одинаковую независимо от локали.

В zsh добавить 0 ко всем числам во всех именах файлов в текущем рабочем каталоге до длины 3 цифры (осторожно, это также усекает более длинные числа до 3 цифр) можно с помощью:

autoload zmv
zmv '*' '${f//<->/${(l[3][0])MATCH}}'

Почему abc.zml-12.gz идет перед abc.zml-1.gz?

потому что 2 “до” ., лексически, в выбранной вами коллации.

ls не пытается сортировать по числам.