Linux сортировка по столбцу grep

COREUTILS. Команда sort. Сортировка вывода программ

Скорее всего пакет coreutils у вас уже установлен, хотя бы потому, что удалить его нельзя, но на всякий случай проверьте:

dpkg -l | grep coreutils #для debian-based дистрибутивов

Если в первой колонке вывода будет стоять буква «i», означающая installed, значит все в порядке.

Пользоваться утилитой sort для сортировки вывода программ предельно просто. Для этого достаточно просто перенаправить вывод какой-либо программы на поток ввода sort:

Данная конструкция сначала вызовет команду ls, которая считает содержимое каталога, а затем передаст результат команде sort, которая отсортирует его по алфавиту (ключ -d указывает использовать алфавит в качестве шаблона).

Другой пример использования команды sort в linux — это сортировка содержимого файла. Отсортируем, например, строки, содержащиеся в файле /etc/passwd, с целью получения имен пользователей по алфавиту:

sort -d /etc/passwd

Но что делать, если вы хотите, используя тот же файл, отсортировать строки уже не по имени пользователя, а, например, по их уникальному идентификатору (UID)? Утилита sort умеет работать и с таблицами — сортировать по столбцу. Вернее изначально, sort как раз и работает с таблицами, вот только в качестве разделителя она по-умолчанию использует пробел и знак табуляции для разделения столбцов, знак переноса строки для разделения строк. Так как файл /etc/passwd использует «:» для разделения столбцов, то этот символ нужно передать sort при помощи ключа «-t» явно, а далее просто указать номер столбца с помощью ключа «-k». Но только ничего не получится, если опять же не указать шаблон. В данном случае нам понадобиться сортировать числа — поэтому вместо «-d» (по алфавиту) стаим -n (по числам). Вот, что получилось:

sort -n -t : -k 2,2 /etc/passwd

Внимательный читатель спросит: «Почему в качестве параметра ключа «-k» мы указали не просто номер столбца, а номер столбца через запятую с его же номером?». Ответ прост. Ключ «-k» очень мощный. Он позволяет гибко выбирать сортируемое поле. Используя предыдущий пример, немного изменим параметры ключа «-k»:

sort -n -t : -k 2.2,2.4 /etc/passwd

Добавив точку, мы тем самым сузили диапазон для проведения сортировки. Теперь команда расшифровывается так: отсортируй содержимое файл /etc/passwd, приняв в качестве исходных данных символ со второго по четвертый во 2-ом столбце.

Приведем еще один классный пример. Представим, что у нас закончилось место в разделе /home, и мы хотим узнать 10 самых объемных каталогов и файлов внутри /home с целью понять, куда копать:

du -a /home | sort -n | tail

Сначала командой du мы проходимся по всем файлам и подкаталогам /home, затем сортируем полученные строки по возрастанию и, наконец, tail’ом отображаем последние 10

На этом возможности команды soft не исчерпываются. Полезным может оказаться ключ «-r», позволяющий сортировать строки в обратном порядке. Его не стоит путать с ключом «-R», который совершенно случайным образом сортирует содержимое файла или вывода программы. Должно быть такая функция тоже кому-то будет полезной.

Также стоит обратить ваше внимание на ключ «-u», который заставляет sort выводит только уникальные значения. Т.е., если при сортировке выяснится, что сортируемые значения одинаковы, будет выведено только то, которое первым попало в поле зрения sort. Ключ «-u» не работает для значений, например «1» и » 1″ (один и пробел один), так как пробел тоже считается символом. Чтобы этого избежать применяют ключ «-b», позволяющий игнорировать пробелы перед сортируемой строкой.

Источник

Команда sort в Linux

Сегодня мы поговорим о команде sort. Это утилита для вывода текстовых строк в определенном порядке. Проще говоря, для сортировки. Ее можно использовать для сортировки текста из одного или нескольких файлов или c помощью нее может быть выполнена сортировка вывода linux для какой-либо команды. Это может быть полезно во многих случаях. Например, отсортировать файлы по размеру в выводе команды du или собрать частотность использования команд из истории.

В этой инструкции мы подробно рассмотрим возможности команды sort Linux, ее опции и разберем несколько примеров использования.

Синтаксис

Уже по традиции подобных статей, сначала рассмотрим общий синтаксис команды:

$ sort опции файл

$ команда | sort опции

Опции

Теперь рассмотрим основные опции утилиты sort.

• -b — не учитывать пробелы
• -d — использовать для сортировки только буквы и цифры
• -i — сортировать только по ASCII символах
• -n — сортировка строк linux по числовому значению
• -r — сортировать в обратном порядке
• -с — проверить был ли отсортирован файл
• -o — вывести результат в файл
• -u — игнорировать повторяющиеся строки
• -m — объединение ранее отсортированных файлов
• -k — указать поле по которому нужно сортировать строки, если не задано, сортировка выполняется по всей строке.
• -f — использовать в качестве разделителя полей ваш символ вместо пробела.

Я понимаю, что многое из всего этого может быть непонятно, но на примерах все станет намного яснее.

Примеры использования sort

Наконец-то мы добрались к теме примеры sort Linux. Давайте сначала создадим файл с несколькими строками, на котором и будем проверять возможности утилиты.

computer
mouse
LAPTOP
data
RedHat
laptop
debian
laptop

Также можно воспользоваться вот такой командой:

echo -e «computer\nmouse\nLAPTOP\ndata\nRedHat\nlaptop\ndebian\nlaptop» > test.txt

Опция -e указывает команде, что нужно обрабатывать спецсимволы, а \n, если кто не знает, не что иное как спецсимвол перевода строки в Linux.

1. Сортировка

Теперь давайте выполним сортировку строк linux в нашем файле:

computer
data
debian
laptop
laptop
LAPTOP
mouse
RedHat

Вот несколько принципов, по которым команда sort linux сортирует строки:

• Строки с цифрами размещаются выше других строк
• Строки, начинающиеся с букв нижнего регистра размещаются выше
• Сортировка выполняется в соответствии алфавиту
• Строки сначала сортируются по алфавиту, а уже вторично по другим правилам.

2. Обратная сортировка

Отсортируем файл в обратном порядке:

RedHat
mouse
LAPTOP
laptop
laptop
debian
data
computer

3. Сортировка по колонке

Отсортируем вывод команды ls по девятой колонке, то есть по имени файла или папки. Колонку укажем опцией -k:

drwxr-xr-x 6 user user 4096 дек 6 14:29 Android
drwx—— 3 user user 4096 янв 14 22:18 Desktop
drwxr-xr-x 12 user user 4096 янв 14 21:49 Documents
drwx—— 5 user user 12288 янв 15 14:59 Downloads
drwxr-xr-x 7 user user 4096 янв 13 11:42 Lightworks

Сортировка вывода Linux выполняется так же просто как и строк из файла.

4. Сортировка по номеру

Отсортируем вывод команды ls по второй колонке. Для сортировки по числовому значению используется опция -n:

drwx—— 5 user user 12288 янв 15 14:59 Downloads
drwxr-xr-x 6 user user 4096 дек 6 14:29 Android
drwxr-xr-x 7 user user 4096 июн 10 2015 Sources
drwxr-xr-x 7 user user 4096 окт 31 15:08 VirtualBox
drwxr-xr-x 7 user user 4096 янв 13 11:42 Lightworks
drwxr-xr-x 8 user user 12288 янв 11 12:33 Pictures

5. Удаление дубликатов

Команда sort Linux позволяет не только сортировать строки, но и удалять дубликаты. Для этого есть опция -u:

computer
data
debian
laptop
LAPTOP
mouse
RedHat

Теперь строчка laptop не повторяется.

6. Сортировка по нескольким полям

Мы можем сортировать данные по нескольким полям. Например, отсортируем вывод ls по второму первично и вторично девятому полях:

ls -l | sort -t «,» -nk2,5 -k9

drwxr-xr-x 2 seriyyy95 seriyyy95 4096 дек 6 14:32 Links
drwxr-xr-x 2 seriyyy95 seriyyy95 4096 янв 13 10:43 tmp
drwx—— 3 seriyyy95 seriyyy95 4096 янв 14 22:18 Desktop
drwxr-xr-x 3 seriyyy95 seriyyy95 4096 мар 28 2015 Журналы
drwx—— 4 seriyyy95 seriyyy95 12288 янв 15 15:42 Загрузки

Вот и все. Мы немного приоткрыли занавесу над возможностями сортировки строк linux с помощью команды sort. Если у вас остались вопросы — спрашивайте в комментариях!

Источник

Как Linux’овский sort сортирует строки

Всё началось с короткого скрипта, который должен был объединить информацию об адресах e-mail сотрудников, полученных из списка пользователей почтовой рассылки, с должностями сотрудников, полученными из базы отдела кадров. Оба списка были экспортированы в текстовые файлы в кодировке Юникод UTF-8 и сохранены с юниксовскими концами строк.

Для объединения файлы были отсортированы юниксовской командой sort и поданы на вход юниксовской программе join, которая неожиданно завершилась с ошибкой:

Просмотр результата сортировки глазами показал, что в целом сортировка правильная, но в случае совпадений мужских и женских фамилий, женские идут перед мужскими:

Выглядит как глюк сортировки в Юникоде или как проявление феминизма в алгоритме сортировки. Первое, конечно, правдоподобнее.

Отложим пока join и сосредоточимся на sort. Попробуем решить задачу методом научного тыка. Для начала, поменяем локаль с en_US на ru_RU. Для сортировки достаточно было бы установить переменную окружения LC_COLLATE, но мы не будем мелочиться:

Ничего не изменилось.

Попробуем перекодировать файлы в однобайтовую кодировку:

Опять ничего не поменялось.

Ничего не поделаешь, придётся искать решение в интернете. Прямо про русские фамилии ничего нет, но есть вопросы про другие странности сортировки. Вот, например, такая проблема: unix sort treats ‘-‘ (dash) characters as invisible. Если кратко, то строки «a-b», «aa», «ac» сортируются как «aa», «a-b», «ac».

Ответ везде стандартный: используйте программистскую локаль «C» и будет вам счастье. Пробуем:

Что-то поменялось. Ивановы выстроились в правильном порядке, правда Ёлкина куда-то сползла. Возвращаемся к исходной задаче:

Сработало без ошибок, как и обещал интернет. И это несмотря на Ёлкину в первой строке.

Проблема вроде бы решена, но на всякий случай попробуем ещё одну русскую кодировку — виндоузовскую CP1251:

Результат сортировки, как ни странно, совпадёт с локалью «C», и весь пример, соответственно, проходит без ошибок. Мистика какая-то.

Я не люблю мистику в программировании, поскольку, обычно, она маскирует ошибки. Придётся всерьёз заняться вопросом как работает sort и на что влияет LC_COLLATE .

В конце я попытаюсь ответить на вопросы:

• почему неправильно сортировались женские фамилии
• почему LANG=ru_RU.CP1251 оказался эквивалентом LANG=C
• почему у sort и join разные представления о порядке отсортированных строк
• почему во всех моих примерах есть ошибки
• наконец, как сортировать строки по своему вкусу

Сортировка в Юникоде

Первой остановкой будет технический отчёт № 10 под названием Unicode collation algorithm на сайте unicode.org. Отчёт содержит много технических деталей, так что я позволю себе привести краткое изложение основных идей.

Collation — «сравнение» строк — основа любого алгоритма сортировки. Сами алгоритмы могут отличаться («пузырьком», «слиянием», «быстрый»), но все они будут использовать сравнение пары строк, для определения порядка их следования.

Сортировка строк на естественном языке — это довольно сложная проблема. Даже в простейших однобайтовых кодировках порядок букв в алфавите, хоть в чём-то отличающемся от английской латиницы, уже не будет совпадать с порядком числовых значений, которыми эти буквы кодируются. Так в немецком алфавите буква Ö стоит между О и P, а в кодировке CP850 она попадает между ÿ и Ü.

Можно попытаться абстрагироваться от конкретной кодировки и рассматривать «идеальные» буквы, которые расположены в некотором порядке, как это сделано в Юникоде. Кодировки UTF8, UTF16 или однобайтовая KOI8-R (если нужно ограниченное подмножестве Юникода) будут давать разные числовые представления букв, но ссылаться при этом на одни и те же элементы базовой таблицы.

Оказывается, что даже построив таблицу символов с нуля, мы не сможем назначить в ней универсальный порядок символов. В различных национальных алфавитах, использующих одинаковые буквы, порядок этих букв может отличаться. Например, во французском языке Æ будет считаться лигатурой и сортироваться как строка AE. В норвежском же языке Æ будет отдельной буквой, которая располагается после Z. Кстати, кроме лигатур типа Æ существуют буквы, записываемые несколькими символами. Так в чешском алфавите есть буква Ch, которая стоит между H и I.

Кроме различия в алфавитах существуют и иные национальные традиции, влияющие на сортировку. В частности возникает вопрос: в каком порядке должны следовать в словаре слова, состоящие из прописных и строчных букв? Также на сортировку могут повлиять особенности использования знаков препинания. В испанском языке в начале вопросительного предложения ставится перевёрнутый вопросительный знак (¿Te gusta la música?). В этом случае очевидно, что вопросительные предложения не должны группироваться в отдельный кластер вне алфавита, а как сортировать строки с другими знаками препинания?

Я не буду останавливаться на сортировке строк в языках сильно отличающихся от европейских. Отмечу, что в языках с направлением письма справа налево или сверху вниз символы в строках, скорее всего, хранятся в порядке чтения, и даже в неалфавитных письменностях есть свои способы посимвольного упорядочения строк. Например, иероглифы могут упорядочиваться по начертанию (ключи китайских иероглифов) или по произношению. Как должны упорядочиваться эмодзи, я, честно говоря, не представляю, но и для них можно что-нибудь придумать.

На основе перечисленных выше особенностей были сформулированы основные требования к сравнению строк, основанных на таблицах Юникода:

• сравнение строк не зависит от положения символов в кодовой таблице;
• последовательности символов, образующих единый символ, приводятся к каноническому виду (A + верхний кружочек это то же, что и Å);
• при сравнении строк символ рассматривается в контексте строки и, при необходимости, объединяется с соседями в одну единицу сравнения (Ch в чешском) или разбивается на несколько (Æ во французском);
• все национальные особенности (алфавит, прописные/строчные, знаки препинания, порядок видов письменности) должны настраиваться вплоть до ручного назначения порядка (эмодзи);
• сравнение важно не только для сортировки, но и во многих других местах, например для задания диапазонов строк (подстановка <А… я>в bash);
• сравнение должно выполняться достаточно быстро.

Кроме того, авторы отчёта сформулировали свойства сравнения, на которые разработчики алгоритма не должны полагаться:

• алгоритм сравнения не должен требовать отдельного набора символов для каждого языка (русский и украинский языки совместно используют большинство символов кириллицы);
• сравнение не должно опираться на порядок символов в таблицах Юникода;
• вес строки не должен являться атрибутом строки, поскольку одна и та же строка в разных культурных контекстах может иметь различные веса;
• веса строк могут меняться при слиянии или разбиении (из x или (где x — шестнадцатеричная цифра). Это шестнадцатеричное представление кодовых точек Юникода в кодировке UCS-4 (UTF-32). Все остальные элементы в угловых скобках (в том числе , и им подобные), считаются простыми строковыми константами, не имеющими особого смысла вне контекста.

Строка LC_COLLATE говорит нам, что далее начинаются данные, описывающие сравнение строк.

Сначала задаются имена для весов в таблице сравнения и имена для комбинаций символов. Вообще говоря, два типа имён принадлежат двум разным сущностям, но в реальном файле они перемешаны. Имена весов задаются ключевым словом collating-symbol (символ сравнения), поскольку при сравнении символы Юникода, имеющие одинаковые веса, будут считаться эквивалентными символами.

Общая длина секции в текущей ревизии файла около 900 строк. Я надёргал примеры из нескольких мест, чтобы показать произвольность имён и несколько видов синтаксиса.

• collating-symbol регистрирует строку OSMANYA в таблице имён весов
• collating-symbol .. регистрирует последовательность имён, состоящих из префикса S и шестнадцатеричного числового суффикса от 1D000 до 1D35F.
• FFFF в collating-symbol выглядит как большое беззнаковое целое в шестнадцатеричной системе счисления, но это просто имя, которое могло бы выглядеть как
• имя означает кодовую точку в кодировке UCS-4
• collating-element from » « регистрирует новое имя для пары юникодовских точек.

Когда имена весов определены, задаются собственно веса. Поскольку при сравнении имеет значение только отношения больше-меньше, то веса определяются простой последовательностью перечисления имён. Сначала перечисляются более «лёгкие» веса, затем более «тяжёлые». Напомню, что каждому юникодовскому символу присваивается четыре разных веса. Здесь они сведены в единую упорядоченную последовательность. Теоретически, любое символическое имя может использоваться на любом из четырех уровней, но комментарии указывают на то, что разработчики мысленно разделяют имена по уровням.

Наконец, собственно таблица весов.

Секция весов заключена в строки с ключевыми словами order_start и order_end. Дополнительные параметры order_start определяют, в каком направлении просматриваются строки на каждом уровне сравнения. По умолчанию используется параметр forward. Тело секции состоит из строк, которые содержат код символа и четыре его веса. Код символа может быть представлен самим символом, кодовой точкой или символическим именем, определённым ранее. Веса также могут задаваться символическими именами, кодовыми точками или самими символами. Если используются кодовые точки или символы, то их вес совпадает с числовым значением кодовой точки (позицией в таблице Юникода). Символы не указанные явно считаются приписанными в таблицу с единственным последним весом, совпадающим с позицией в таблице Юникода. Специальное значение веса IGNORE означает, что на соответствующем уровне сравнения данный символ игнорируется.

Для демонстрации структуры весов я выбрал три достаточно очевидных фрагмента:

• символы, которые игнорируются полностью
• символы эквивалентные цифре три на первых двух уровнях
• начало кириллического алфавита, который не содержит диакритических знаков, а потому сортируется, в основном, по первому и третьему уровням.

Теперь можно снова вернуться к сортировке примеров из начала статьи. Засада кроется вот в этой части таблицы весов:

Видно, что в этой таблице знаки препинания из таблицы ASCII (включая пробел) при сравнении строк практически всегда игнорируются. Исключение составляют лишь строки, совпадающие во всём, кроме знаков препинания, встречающихся в совпадающих позициях. Строки из моего примера (после сортировки) для алгоритма сравнения выглядят так:

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

При установке переменной LC_COLLATE=C загружается особая таблица, которая задаёт побайтовое сравнение

Поскольку в Юникоде кодовая точка Ё стоит перед А, то и строки сортируются соответственно.

Текстовые и двоичные таблицы

Очевидно, что сравнение строк, это чрезвычайно часто встречающаяся операция, а разбор таблицы CTT довольно затратная процедура. Для оптимизации доступа к таблице она компилируется в двоичную форму командой localedef.

Команда localedef принимает в качестве параметров файл с таблицей национальных особенностей (опция -i), в котором все символы представлены точками Юникода, и файл соответствия точек Юникода символам конкретной кодировки (опция -f). В результате работы создаются двоичные файлы для локали, с именем указанным в последнем параметре.

Glibc поддерживает два формата двоичных файлов: «традиционный» и «современный».

Традиционный формат подразумевает, что имя локали, это имя подкаталога в /usr/lib/locale/. В этом подкаталоге хранятся двоичные файлы LC_COLLATE, LC_CTYPE, LC_TIME и т.п. Файл LC_IDENTIFICATION содержит формальное имя локали (которое может отличаться от имени каталога) и комментарии.

Современный формат предполагает хранение всех локалей в едином архиве /usr/lib/locale/locale-archive, который отображается в виртуальную память всех процессов, использующих glibc. Имя локали в современном формате подвергается некоторой канонизации — в названия кодировки остаются только цифры и буквы, приведённые к нижнему регистру. Так ru_RU.KOI8-R, будет сохранено как ru_RU.koi8r.

Входные файлы ищутся в текущем каталоге, а так же в каталогах /usr/share/i18n/locales/ и /usr/share/i18n/charmaps/ для файлов CTT и файлов кодировок соответственно.

скомпилирует файл /usr/share/i18n/locales/ru_RU с использованием файла кодировки /usr/share/i18n/charmaps/MAC-CYRILLIC.gz и сохранит результат в /usr/lib/locale/locale-archive под именем ru_RU.maccyrillic

Если установить переменную LANG=en_US.UTF-8 то glibc будет искать двоичные файлы локали в следующей последовательности файлов и каталогов:

Если локаль встречается и в традиционном и в современном форматах, то приоритет отдаётся современному.

Просмотреть список скомпилированных локалей можно командой locale -a.

Подготовка своей таблицы сравнения

Теперь, вооружившись знаниями, можно создать собственную идеальную таблицу сравнения строк. Эта таблица должна корректно сравнивать русские буквы, включая букву Ё, и при этом учитывать знаки препинания в соответствии с таблицей ASCII.

Процесс подготовки своей таблицы сортировки состоит из двух этапов: редактирования таблицы весов и компиляции её в двоичную форму командой localedef.

Для того, чтобы таблицу сравнения можно было бы подстроить с минимальными затратами на редактирование, в формате ISO 14652 предусматриваются секции корректировки весов уже существующей таблицы. Секция начинается с ключевого слова reorder-after и указания позиции, после которой выполняется замена. Завершает секцию строка reorder-end. Если необходимо поправить несколько участков таблицы, то создаётся по секции на каждый такой участок.

Я скопировал новые версии файлов iso14651_t1_common и ru_RU из репозитория glibc в свой домашний каталог

/.local/share/i18n/locales/ и слегка подредактировал раздел LC_COLLATE в ru_RU. Новые версии файлов полностью совместимы с моей версией glibc. Если вы захотите использовать старые версии файлов, то вам придётся поменять символические имена и место, с которого начинается замена в таблице.

На самом деле, надо было бы поменять поля в LC_IDENTIFICATION так чтобы они указывали на локаль ru_MY, но в моём примере это не потребовалось, поскольку я исключил из поиска локалей архив locale-archive.

Чтобы localedef работала с файлами в моей папке через переменную I18NPATH можно добавить дополнительный каталог для поиска входных файлов, а каталог для сохранения двоичных файлов можно указать в виде пути со слэшами:

POSIX предполагает, что в LANG можно писать абсолютные пути к каталогам с файлами локалей, начинающиеся с прямого слэша, но glibc в Linux все пути считает от базового каталога, который можно переопределить через переменную LOCPATH. После установки LOCPATH=

/.local/lib/locale/ все файлы, связанные с локализацией будут искаться только в моей папке. Архив локалей при установленной переменной LOCPATH игнорируется.

Вот он решающий тест:

Ура! Мы сделали это!

Работа над ошибками

Я уже ответил на вопросы о сортировке строк, поставленные в начале, но ещё осталась пара вопросов об ошибках — видимых и невидимых.

Вернёмся к исходной задаче.

И программа sort и программа join используют одни и те же функции сравнения строк из glibc. Как же получилось, что join выдавала ошибку сортировки на строках, отсортированных командой sort в локали en_US.UTF-8? Ответ прост: sort сравнивает строку целиком, а join сравнивает только ключ, которым по умолчанию, является начало строки до первого пробельного символа. В моём примере это привело к сообщению об ошибке поскольку сортировка первых слов в строках не совпала с сортировкой полных строк.

Локаль «C» гарантирует, что в отсортированных строках начальные подстроки до первого пробела также окажутся отсортированными, но это только маскирует ошибку. Можно подобрать такие данные (люди с одинаковыми фамилиями, но разными именами), которые без сообщения об ошибке дали бы неправильный результат слияния файлов. Если мы хотим, чтобы join объединял строки файлов по ФИО, то правильным способом будет явное указание разделителя полей и сортировка по ключевому полю, а не по всей строке. В этом случае и слияние пройдёт правильно и ни в какой локали не будет ошибок:

Успешно выполнившийся пример в кодировке CP1251 содержит ещё одну ошибку. Дело в том, что во всех известных мне дистрибутивах Linux в пакетах отсутствует скомпилированная локаль ru_RU.CP1251. Если скомпилированная локаль не найдена, то sort молча использует побайтовое сравнение, что мы и наблюдали.

Кстати, есть ещё один маленький глюк связанный с недоступностью скомпилированных локалей. Команда LOCPATH=/tmp locale -a выдаст список всех локалей в locale-archive, но при установленной переменной LOCPATH для всех программ (в том числе и для самой locale) эти локали будут недоступны.

Заключение

Если вы программист, который привык считать, что строки это набор байтов, то ваш выбор LC_COLLATE=C.

Если вы лингвист или составитель словарей, то вам лучше скомпилировать свою локаль.

Если вы простой пользователь, то вам достаточно привыкнуть к тому, что команда ls -a выдаёт файлы, начинающиеся с точки, вперемешку с файлами, начинающимися с буквы, а Midnight Commander, который использует свои внутренние функции для сортировки имён, выносит файлы, начинающиеся с точки, в начало списка.

Источник