web-dev-qa-db-ja.com

CentOS7でLANG = Cを設定するとコンソールログインが中断するのはなぜですか

私は通常、すべてのロケール設定を「C」に設定します。それは私が慣れているものです。私はlsが好きで、過去数十年の間私が慣れている方法で物事を分類します。

LANG=Cに.bashrcを設定したときの驚きと失望を想像してみてください。ログインすると、ウィンドウマネージャーがありません。

これは修正可能ですか？

更新：LC_ALL=Cの可能性があります。 2つのうちの1つはそれを壊しています。 LC_COLLATE=Cはいくつかの問題を修正しますが、他の問題は修正しません。

-E

Linux xxxx 3.10.0-957.10.1.el7.x86_64 #1 SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
linuxcentosgnome3gdm
1
Erik Bennett

ロケール設定の影響を受けるシステムに関連する機能の1つは、LC_CTYPEパラメーターから取得したテキストエンコーディング、または「charset」または「codepage」です。多くの場合、テキストエンコーディングは仕様によって指定されますが（たとえば、D-Busプロトコル文字列は常にUTF-8です）、エンコーディングが指定されておらず、現在のシステムロケールから取得する必要がある場所も多くあります。

特に、filenamesは、現在のロケールテキストエンコーディングに従って頻繁に表示されます。たとえば、Python 3で記述されたプログラムは、プログラムが別の方法で指定するのを忘れた場合、現在のロケールエンコーディングを使用します。

「C」ロケールは7ビットASCIIテキストエンコーディング（ANSI_X3.4-1968））を意味し、問題の一部は、多くのプログラム（一般にCで記述されたもの）がこれを解釈することである可能性があります任意の8ビット値を許可するために、はるかに厳密な解釈を持ち、拒否 127を超える値（つまり非ASCII）が無効であるプログラムも多数あります。デコードエラーが発生している可能性があります。いくつかのファイル名、またはいくつかの構成パラメーター、またはいくつかの他のテキストファイルによって。

実際、この時点で、ASCIIテキストエンコーディングを指定するロケールでの動作を完全に拒否するプログラムもあります。その中には、特にUTF-8を必要とするものもあります（gnome-terminalなど）。 ）、および8ビットエンコーディングを必要とするその他のいくつか。

ディストリビューションが「C.UTF-8」パッチをlibcに適用する場合は、それを使用します。

LANG=C.UTF-8

そうでない場合は、次のいずれかを使用します。

 LANG = en_US.UTF-8 
 LC_TIME = C 
 LC_COLLATE = C 
 LC_MESSAGES = C 

 LANG = C 
 LC_CTYPE = en_US.UTF-8

（locale charmapを実行して、現在の環境変数に従って有効なコードページを確認できます。どちらの場合もUTF-8と表示されます。3番目のオプションを選択する場合は、代わりに$ LANGを直接参照するバグのあるプログラムに注意してください。 nl_langinfo（CODESET）を呼び出す必要があります。）

2
user1686