Saya tidak membahas detail siapa yang "benar atau salah" - tetapi sama-sama kesal dengan masalah ini. Beberapa solusi untuk ini:
- Sisi server:
- ubah/nonaktifkan
AcceptEnv LC_*di/etc/ssh/sshd- kontra:menyetelnya ke sistem-default
- edit
.profile- kontra:pengguna tunggal
- edit
/etc/bash*atau/etc/profile- kontra:dapat dibalik dalam pembaruan
- ubah/nonaktifkan
- Sisi klien:
alias ssh="LC_CTYPE=\"${LANG}\" ssh"di.bashrc/.profile/dimanapun- kontra:pengguna tunggal
- sama seperti sisi server di
.bashrc/.profile... - ubah/tambahkan pengaturan di Terminal
- con:seluruh sesi, baik lokal maupun jarak jauh
Jadi, pada akhirnya saya membuat mac-locale-fix.sh di /etc/profile.d di server (raspian dalam kasus saya) dengan baris ini di dalamnya:
[ "A${LC_CTYPE}" == "AUTF-8" ] && export LC_CTYPE="${LANG}"
Semoga ini bisa membantu orang lain...
Pertanyaan dasarnya adalah
Pertanyaan utama saya adalah, apakah ini bug di MacOS? Atau apakah Linux salah dalam bersikeras bahwa variabel harus disetel ke nama lokal yang ditentukan sepenuhnya?
dan halaman POSIX untuk variabel lingkungan menunjukkan alasan mengapa orang lain menganggap konfigurasi macOS salah:
[XSI] Jika nilai lokal memiliki bentuk:
language[_territory][.codeset]mengacu pada lokal yang disediakan oleh implementasi, dengan setelan bahasa, wilayah, dan kumpulan kode ditentukan oleh implementasi .
LC_COLLATE,LC_CTYPE,LC_MESSAGES,LC_MONETARY,LC_NUMERIC, danLC_TIMEdidefinisikan untuk menerima bidang tambahan @ pengubah, yang memungkinkan pengguna untuk memilih contoh spesifik dari data pelokalan dalam satu kategori (misalnya, untuk memilih kamus sebagai kebalikan dari urutan karakter data). Sintaks untuk variabel lingkungan ini didefinisikan sebagai:[language[_territory][.codeset][@modifier]]Misalnya, jika pengguna ingin berinteraksi dengan sistem dalam bahasa Prancis, tetapi harus mengurutkan file teks Jerman, LANG dan LC_COLLATE dapat didefinisikan sebagai:
LANG=Fr_FR LC_COLLATE=De_DEIni dapat diperluas untuk memilih susunan kamus (katakanlah) dengan menggunakan bidang @ pengubah; misalnya:
[email protected]Penerapan mungkin mendukung format lain.
Jika nilai lokal tidak dikenali oleh penerapan, perilaku tidak ditentukan.
Artinya, mereka berasumsi bahwa POSIX menentukan sintaks untuk pengaturan lokal. Pembaca yang tidak waspada akan berasumsi bahwa POSIX menentukan bentuk yang diizinkan untuk variabel lingkungan sehingga kumpulan kode value bersifat opsional, dan tidak bertindak sebagai pengganti bahasa . Tapi "mungkin" terakhir itu membuka sekaleng cacing, yang pada dasarnya memberkati perbedaan interpretasi ini. Apple dapat melakukan apa pun yang diinginkannya, jika ingin menyediakan lokal yang valid yang tidak persis mengikuti pola tersebut.
@tripleee menyarankan agar halaman di Lokal memberikan informasi yang lebih baik, tetapi itu hampir seluruhnya merupakan diskusi tentang definisi lokal daripada memberikan panduan untuk interoperabilitas (yaitu, tujuan nyata POSIX).
Tidak ada halaman yang membahas perbedaan dalam pengaturan lokal yang tersedia (seperti ".utf8" versus ".UTF-8"). Itu bergantung pada implementasi, seperti yang tercantum pada halaman POSIX. Itu membuat pengguna dengan satu-satunya solusi untuk menentukan sendiri pengaturan lokal apa yang didukung pada sistem lokal dan jarak jauh, dan (perilaku ssh di sini) menentukan cara mengaturnya pada sistem jarak jauh "kompatibel".