У вас есть 19 ГБ ОЗУ, свободной для программ.Нет необходимости очищать дисковый кеш: система освободит его, если память понадобится для других целей, например для запуска программы. Единственное, что вы можете сделать, очистив дисковый кеш, - это замедлить работу вашего компьютера.
Место на диске не имеет значения. Удаление файлов вам не поможет.
У вас 19 ГБ ОЗУ, и программа утверждает, что не может выделить 26 МБ. Посчитайте: 26 МБ <19 ГБ. Это ошибка программы либо в том, как она выделяет память, либо в том, как она сообщает об ошибках. Проверьте /tmp/hs_err_pid50274.log
, чтобы узнать, есть ли в нем дополнительные подсказки.
Алгоритмы сортировки в современных регионах довольно сложны.
Каждому символу (фактически элементу сопоставления , который может состоять из последовательности из нескольких символов, например, чешского ch
) присваивается число весов сопоставления , которые определяют порядка их сортировки.
При сравнении двух строк сначала используется первый вес всех символов, а другие веса используются позже для определения связи, если две строки отсортированы одинаково с первыми весами.
Например, во многих регионах e
, é
и E
имеют одинаковый первичный вес (они имеют одинаковый класс эквивалентности, все они соответствуют [= e =]
).
Итак, при сравнении, например, echo
, été
и введите
, в первом проходе, e
, é
и E
, имеющие одинаковый основной вес, второй символ будет определять порядок ( c
до n
до t
).
При сравнении été
, Été
, Ete
, после первого прохода все они сортируются одинаково, поэтому мы используем второй проход с вторичным весом. .В типичных языковых стандартах GNU второй вес для символов латинского алфавита используется для определения приоритета акцентов (сначала не ставится ударение, а затем острый, серьезный, бревный, циркумфлексный ...). Затем нам нужно будет использовать третий вес, чтобы выбрать между été
и Été
, и это будет основано на регистре (сначала строчные буквы в большинстве языков). Есть даже символы, которые в конечном итоге сортируются одинаково, потому что все их веса идентичны.
Используется для сортировки текста аналогично словарям, как это делают люди.
В словаре вы обнаружите, что пробелы и большинство знаков пунктуации также игнорируются. Например, де-факто
занимает промежуточное положение между дебютным
и лишенным
. Первый вес пробела - ИГНОРИРОВАТЬ.
В системе GNU вы найдете основные правила сортировки, определенные в / usr / share / i18n / locales / iso14651_t1_common
(путь может отличаться в зависимости от дистрибутива). Там вы увидите:
ifdef UPPERCASE_FIRST
<CAP>
else
<MIN>
endif
[...]
ifdef UPPERCASE_FIRST
[...]
<MIN> # 10
[...]
else
[...]
<CAP> # 9
[...]
endif
[...]
order_start <SPECIAL>;forward;backward;forward;forward,position
<U0020> IGNORE;IGNORE;IGNORE;<U0020> # 32 <SP>
[...]
<U003E> IGNORE;IGNORE;IGNORE;<h> # 140 >
[...]
ifdef DIACRIT_FORWARD
order_start <LATIN>;forward;forward;forward;forward,position
else
order_start <LATIN>;forward;backward;forward;forward,position
endif
[...]
<U0065> <e>;<BAS>;<MIN>;IGNORE # 259 e
<U00E9> <e>;<ACA>;<MIN>;IGNORE # 260 é
[...]
<U0045> <e>;<BAS>;<CAP>;IGNORE # 577 E
<U00C9> <e>;<ACA>;<CAP>;IGNORE # 578 É
Что иллюстрирует то, что мы только что сказали. И для пробела, и для >
первые 3 веса имеют значение IGNORE
. Их относительный порядок будет учитываться только для строк, сортирующих одинаково для первых трех весов (>
перед пробелом, так как
будет перечисляться перед неуказанным символом сортировки
).
В региональных стандартах, определяющих UPPERCASE_FIRST
(например, / usr / share / i18n / locales / tr_TR
), сначала будут идти буквы верхнего регистра (в 3 rd ] проходить).То же самое с DIACRIT_FORWARD
, где некоторые локали, такие как de_DE
, могут изменить порядок диакритических знаков для 2 -го прохода.
>
и >>
сортируют одинаково на 1 -м , 2 -м и 3 -м проходах. В 4 -м , >
сортируются до >>
, поскольку пустая строка сортируется перед всем.
>> b
сортирует после b
, потому что они сортируют одинаково в первых 3 проходах, но на четвертом проходе b
ИГНОРИРОВАТЬ, поэтому >
больше. Это меньше, чем c
на первом проходе (>
игнорируется, и b
перед c
) ... Вы уловили идею.
Теперь, если вы посмотрите на определение локали C
. Все намного проще. Есть только один вес, и вес основан на значении кодовой точки от U + 0000 до U + 10FFFF. Итак, SPC
(U + 0020) сортируется перед >
(U + 003E), который сортируется перед b
(U + 0062), который сортируется перед c
(U + 0063). Ни один персонаж никогда не игнорируется.
Обратите внимание, что по крайней мере с GNU libc этот порядок, определенный в файле определения локали C, игнорируется, когда дело доходит до функций сравнения ( strcoll ()
и т. Д., Используемых в sort
). Независимо от значения LC_CTYPE
, с LC_COLLATE = C
, strcoll ()
эквивалентно strcmp ()
.Поскольку при сравнении всегда используется значение байта, даже если эти байты соответствуют символам, кодовая точка юникода которых сортируется наоборот (например, 0xA4 U + 20AC EURO SIGN против A5 U + 00A5 YEN SIGN в кодировке ISO-8859-15) ,поэтому LC_ALL = C sort
и LC_COLLATE = C sort
(при условии, что LC_ALL
не установлен иначе) будут иметь тот же эффект.
Из справочной страницы sort (1)
:
*** WARNING *** The locale specified by the environment affects sort order. Set
LC_ALL=C to get the traditional sort order that uses native byte values.
Чтобы отсортировать по байтовому значению, используйте:
LC_ALL=C sort test
В противном случае, sort
будет игнорировать начальные символы до тех пор, пока не найдет ключ, по которому можно выполнить сортировку, поэтому >> b
и b
оказываются рядом друг с другом.