Вопросы Теги

Почему сортировка ls игнорирует неалфавитно-цифровые символы?

Можно попробовать простым бесконечным циклом:

while true; do
  python myapp.py
done

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

 until `python myapp.py; echo $?`; do
     echo "exit ok, restarting"
 done
26
01.04.2012, 13:00
3 ответа

Это не имеет никакого отношения к набору символов. Скорее это - язык, который определяет порядок сопоставления. libc исследует язык, представленный в $LC_COLLATE/$LC_ALL/$LANG и ищет его правила сопоставления (например. /usr/share/i18n/locales/* для GLibC) и заказы текст, как направлено.

10
27.01.2020, 19:40
  • 1
    К вашему сведению: это более сложно, чем это. Если нужно было использовать strcoll например, Вы видели бы что что-то как aasa.c был бы отсортирован выше aas.c. –  Don Scott 05.10.2015, 00:19

Править: Добавленный тест для данных отсортирован с LC_COLLATE=C

Значение по умолчанию сопоставляет последовательность, рассматривает те символы "типа пунктуации", как являющиеся равной ценности.. Use LC_COLLATE=C рассматривать их в порядке кодовой точки.. 

for i in 'a1' 'a_1' 'a-1' 'a,1' 'a.1' 'a2' 'a_2' 'a-2' 'a,2' 'a.2' ;do
  echo $i; 
done |LC_COLLATE=C sort

Вывод 

a,1
a,2
a-1
a-2
a.1
a.2
a1
a2
a_1
a_2

Следующий код тестирует все допустимые символы UTF-8 в Основной Многоязычной Плоскости (за исключением \x00 и \x0a; для простоты)
Это сравнивает файл в известной (сгенерированной) возрастающей последовательности против того файла, случайным образом отсортированного и затем отсортированного снова с LC_COLLATE=C. Результат показывает, что последовательность C идентична исходной сгенерированной последовательности. 

{ i=0 j=0 k=0 l=0
  for i in {0..9} {A..F} ;do
  for j in {0..9} {A..F} ;do
  for k in {0..9} {A..F} ;do
  for l in {0..9} {A..F} ;do
     (( 16#$i$j$k$l == 16#0000 )) && { printf '.' >&2; continue; }
     (( 16#$i$j$k$l == 16#000A )) && { printf '.' >&2; continue; }
     (( 16#$i$j$k$l >= 16#D800    && 
        16#$i$j$k$l <= 16#DFFF )) && { printf '.' >&2; continue; }
     (( 16#$i$j$k$l >= 16#FFFE )) && { printf '.' >&2; continue; }
     echo 0x"$i$j$k$l" |recode UTF-16BE/x4..UTF-8 || { echo "ERROR at codepoint $i$j$k$l " >&2; continue; } 
     echo 
  done
  done
  done; echo -n "$i$j$k$l " >&2
  done; echo >&2
} >listGen

             sort -R listGen    > listRandom
LC_COLLATE=C sort    listRandom > listCsort 

diff <(cat listGen;   echo "last line of listOrig " ) \
     <(cat listCsort; echo "last line of listCsort" )
echo 
cmp listGen listCsort; echo 'cmp $?='$?

Вывод:

63485c63485
< last line of listOrig 
---
> last line of listCsort

cmp $?=0
12
27.01.2020, 19:40
  • 1
    Где это документируется? Та часть стандарта Unicode? –  daniel kullmann 01.04.2012, 13:04
  • 2
    На самом деле они не получают то же значение; те символы просто проигнорированы при сортировке. Если их рассматривали как наличие равного значения, порядка сортировки a_1 a2 a_2 было бы невозможно. –  daniel kullmann 01.04.2012, 13:07
  • 3
    +1 для Вашей тяжелой работы и примера кода. После многих часов, сортируя имена каталогов с пунктуацией для соответствия пути tree это я думаю, что существует больше к истории, такой как пунктуация, удаляемая из строк сравнения или чего-то как этот. Я могу сказать / символ еще должен быть установлен как самый низкий символ в сортирующей последовательности независимо от того, что. –  WinEunuuchs2Unix 01.05.2017, 01:14

У меня точно такая же проблема с параметрами сортировки по умолчанию в Debian, для меня это запятая, которую он игнорирует, и это мешает мне сортировать данные CSV, эффективно вызывая хаос в моем ИИ.

Решение состоит в том, что вместо того, чтобы использовать sortотдельно, мне нужно заставить sort выйти из поведения по умолчанию, которое кажется -d, --dictionary-order.

Запуск команды:

sort -V

Исправляет мою проблему и учитывает запятые.

3
27.01.2020, 19:40

Теги

Похожие вопросы