web-dev-qa-db-ja.com

句読点を尊重するUnicode対応のLC_COLLATEソート順はありますか？

私の知る限り、環境変数LC_COLLATE=en_US.utf8を設定すると、lsのようなプログラムがファイルをソートする方法に関して、LC_COLLATE=cと比較して4つの点が変わります。

  1. Unicode文字は保持されます（??ガベージに置き換えられるのではなく）
  2. アクセントと発音区別符号並べ替え順序には影響しません
  3. ケースの違い並べ替え順序には影響しません
  4. 句読文字（ドットなど）は並べ替え順序に影響しません

機能1は、この時代になくてはならないものです。
機能2と3も優れています。これにより、実際のUnicodeファイル名をより便利に処理できるようになります。
一方、機能4は、ドットが使用される傾向があるLinuxファイル名に対して直感に反する並べ替え順序を生成することが多いため、日常業務で非常に非生産的であると感じています。接尾辞を区切るか、ドットファイルを示します。ファイル名を並べ替えるときにドットを無視するのが良い考えだと誰もが思った理由は本当に想像できません。

例えば：

$ touch foo.txt foo2.txt foó3.txt foo4.txt

$ LC_COLLATE=en_US.utf8 ls
foo2.txt  foó3.txt  foo4.txt  foo.txt

$ LC_COLLATE=c ls
foo.txt  foo2.txt  foo4.txt  fo??3.txt

どちらも満足のいくものではありません。これは私がそれらのファイルをソートしたい方法です：

foo.txt  foo2.txt  foó3.txt  foo4.txt

つまり、句読点が重要な文字（文字の前にソートされる）として扱われることを除いて、LC_COLLATE=en_US.utf8と同じです。

これを行うLC_COLLATE設定はありますか？

すべての機能1〜3をサポートする句読点を尊重する句読点がない場合、機能1をサポートする句読点が少なくとも1つありますか（つまり、LC_COLLATE=cのように並べ替えますが、Unicode文字を文字化けさせません）？

linuxshellunicodesortinglocale
6
smls

問題番号1は、LC_COLLATE=cは無効なロケールです。大文字が必要ですC（LC_COLLATE=C）：

$ LC_COLLATE=c ls -1a
./
../
.sharp
.zharp
Sharp
sharp
szharp
zharp
??harp

$ LC_COLLATE=C ls -1a
./
../
.sharp
.zharp
Sharp
sharp
szharp
zharp
ßharp

Unicode対応の並べ替えを行う方法がわかりませんなしファイル名を上にドットで並べ替えます（これに対する答えを検索すると、ここで終わりました）：-/

2
Martin Tournoij