Portabilitas lokal UTF-8 (dan ssh)

Saya menghabiskan banyak waktu saya sshdengan berbagai mesin, yang semuanya berbeda (ada yang tertanam, ada yang menjalankan Linux, ada yang menjalankan BSD, & c.). Pada komputer lokal saya sendiri, bagaimanapun, saya menggunakan OS X, yang tentu saja memiliki userland berdasarkan BSD. Lokal saya pada mesin-mesin itu diatur ke en_GB.UTF-8, yang merupakan salah satu opsi yang tersedia:

% echo `sw_vers`
ProductName: Mac OS X ProductVersion: 10.8.2 BuildVersion: 12C60
% locale -a | grep -i 'en_gb.utf'
en_GB.UTF-8

Beberapa sistem Linux yang lebih berkemampuan yang saya gunakan tampaknya memiliki opsi yang setara, tetapi saya perhatikan bahwa di Linux namanya sedikit berbeda:

% lsb_release -d
Description: Debian GNU/Linux 6.0.3 (squeeze)
% locale -a | grep -i 'en_gb.utf' 
en_GB.utf8

Ini membuat saya bertanya-tanya: Ketika saya sshmasuk ke mesin Linux dari Mac saya, dan itu meneruskan semua LC_*variabel saya dengan akhiran 'UTF-8', apakah mesin Linux itu bahkan mengerti apa yang diminta? Atau apakah itu jatuh kembali ke tempat lain?

edit: Ini adalah contoh dari apa yang saya maksudkan:

% ssh -v odin
...
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_ALL = en_GB.UTF-8
debug1: Sending env LC_COLLATE = en_GB.UTF-8
debug1: Sending env LC_CTYPE = en_GB.UTF-8
debug1: Sending env LC_MESSAGES = en_GB.UTF-8
debug1: Sending env LC_MONETARY = en_GB.UTF-8
debug1: Sending env LC_NUMERIC = en_GB.UTF-8
debug1: Sending env LC_TIME = en_GB.UTF-8
debug1: Sending env LANG = en_GB.UTF-8
odin:~ % locale | tail -1  # locale is set to .UTF-8 without error...
LC_ALL=en_GB.UTF-8
odin:~ % locale -a | grep 'en_GB.UTF-8'  # ... even though .UTF-8 isn't an option
odin:~ %

Dalam kedua kasus, apa mekanisme di balik perilakunya, dan apakah itu tergantung pada pengaturan tertentu (misalnya, apakah saya akan melihat perilaku yang sama pada sistem berbasis BusyBox seperti pada yang berbasis GNU)?

— Kine
sumber

Penjelasan di sana: superuser.com/questions/999133/… (jawaban dari grawity). Jadi dari BSD ke Linux tidak ada masalah. Dari Linux (jika mendefinisikan utf8, bukan UTF-8) ke BSD, mungkin ada masalah.

— AB

Jawaban:

Ini pertanyaan yang menarik, tapi saya pikir mungkin ada kesalahpahaman di sana tentang bagaimana variabel diatur. Ketika sesi shell aman dimulai ( ssh remotehost), apa yang terjadi di ujung yang lain adalah instance dari shell baru dengan lingkungan yang terpisah. Itu adalah cara yang bagus untuk mengatakan bahwa server memulai shell baru. Shell baru itu mungkin atau tidak dapat dikonfigurasi dengan lokal yang sama dengan shell lokal asli Anda.

Misalnya

geee: ~
$ echo `locale | grep LANG` ::` date`
LANG = en_US.UTF-8 :: Sen 3 Des 07:04:00 CET 2012

$ ssh flode
flode: ~
$ echo `locale | grep LANG` ::` date`
LANG = nb_NO.UTF-8 LANGUAGE = nb_NO.UTF-8 :: ma. 03. des. 06:59:33 +0100 2012

Untuk mendemonstrasikan ini, saya mengatur lokal pada shell jarak jauh untuk Norwegia dengan menambahkan baris berikut ke file ~ / .bash_profile:

export     LANG=nb_NO.UTF-8
export LANGUAGE=nb_NO.UTF-8
export   LC_ALL=nb_NO.UTF-8

Demikian pula, Anda harus mengatur lingkungan pada shell jarak jauh untuk melakukan hal yang sama. Tentu saja, shell lain membaca file startup yang berbeda seperti ~ / .zprofile untuk shell Z.

Kesalahpahaman yang saya curigai adalah bahwa variabel lokal (pengaturan) sama sekali tidak diteruskan. Shell jarak jauh memiliki pengaturannya sendiri. Untuk membuat daftar bahasa yang tersedia pada host jarak jauh, baik itu shell BusyBox minimalis atau OS GNU yang lengkap, gunakan localeperintah dengan -asakelar (seperti disebutkan dalam pertanyaan). Setiap garis yang dicetak dapat digunakan sebagai pengaturan lokal untuk lingkungan itu.

Sedangkan untuk pertanyaan pertama, lokal default yang diawali dengan shell biasanya dikonfigurasi di tempat sentral seperti / etc / profile. Sebagian besar kulit login membaca file ini saat startup.

— Ярослав Рахматуллин
sumber

Hal-hal lokal pasti diteruskan. /etc/ssh_configpada setiap mesin yang pernah saya lihat mendefinisikannya LANGdan LC_*dikirim ke semua host secara default, dan ssh -vmengungkapkan beberapa baris seperti debug1: Sending env LC_ALL = en_GB.UTF-8. Tentu saja, jika profil shell di ujung yang lain kemudian menimpanya, itu hal lain - tetapi pada beberapa mesin saya, itu tidak terjadi

— kine

PS: Saya telah memperbarui posting asli saya dengan mungkin ilustrasi yang lebih baik tentang apa yang saya maksudkan

— kine

Memang saya belum pernah melihat ini. Mesin yang Anda maksud, Debian? Mungkin ini akan menjelaskan mekanisme ssh-forwarding ssh. Saya masih berpikir bahwa nama lokal harus sama persis, karena lokal tidak seharusnya cukup pintar untuk mengetahuinya. Alasan mengapa string berbeda adalah karena pustaka C berbeda untuk mesin berbasis BSD dan GNU / Linux. Mereka tidak saling kenal. Tetapi mungkin saya terlalu skeptis dan program lokal memiliki cara untuk menyesuaikan ini secara otomatis.

— Ярослав Рахматуллин

Itu adalah bagian yang saya ingin tahu tentang - sshhal-hal penerusan tidak disengaja, itu hanya konteks mengapa lokal saya diatur seperti itu. Saya hanya tidak tahu bagaimana menentukan apa yang sebenarnya dilakukan oleh shell di ujung yang lain - saya biasanya tidak mendapatkan kesalahan saat mencoba mengatur lokal (walaupun saya terkadang melakukannya pada perangkat yang disematkan), dan input / tampilan teks Unicode tampak seperti bekerja secara normal (?), tetapi lokal yang saya gunakan jelas tidak ada pada sistem. Sebagian besar perangkat Linux yang saya hubungkan adalah berbasis Debian atau Ubuntu, sementara yang lain berbasis uClibc / BusyBox (peralatan jaringan, & c.).

— Kine

Apakah nama untuk dukungan UTF-8 sedikit berbeda pada sistem yang berbeda untuk perintah berikut juga?

LC_ALL='' locale charmap  # UTF-8 (on Mac OS X 10.6.8)

Jika Anda mengalami masalah terkait lokal yang aneh, mungkin membantu untuk memberitahu klien SSH untuk tidak mengirim LC_*variabel tersebut dengan berkomentar SendEnv LANG LC_*di /etc/ssh_config(lihat, misalnya, Memperbaiki Masalah SSH UTF-8 Mac OS X Lion dan Terminal di OS X Lion: can dapat menulis åäö di mesin jarak jauh ).

Pendekatan solusi lain adalah ini:

# from: http://mod16.org/hurfdurf/?p=189
tjac wrote:
Actually the real problem that's causing this is that Mac OS 10.7 sets totally 
non-standard locale values, at least when you tweak some of the formats in
SysPrefs/Language&Text as I did.

If you type "locale" on your Mac terminal you should see pretty much the same as on 
other Unices (e.g. lots of en_US.UTF-8s if you prefer US English), but you don't. 
If these garbled settings get transferred to other Unix hosts by the SendEnv option 
they naturally do not know what's going on.

So if you want to fix it cleanly to allow for sshing to all kinds of remote hosts,
including those with older character sets, put the following lines in your 
~/.bash_profile on your Mac client machine.

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Monday, September 12, 2011 at 22:54 #

— karly
sumber