Ich ging nicht auf die Details ein, wer "richtig oder falsch" ist - war aber gleichermaßen verärgert über das Problem. Einige Lösungen dazu:
- Serverseitig:
AcceptEnv LC_*ändern/deaktivieren in/etc/ssh/sshd- Nachteile:es setzt sie auf den Systemstandard
- bearbeite
.profile- Nachteile:Einzelnutzer
- bearbeite
/etc/bash*oder/etc/profile- Nachteile:können in Updates rückgängig gemacht werden
- Clientseitig:
alias ssh="LC_CTYPE=\"${LANG}\" ssh"in.bashrc/.profile/whereEver- Nachteile:Einzelnutzer
- dasselbe wie serverseitig in
.bashrc/.profile... - Einstellungen im Terminal ändern/hinzufügen
- con:gesamte Sitzung, sei es lokal oder remote
Am Ende habe ich also mac-locale-fix.sh erstellt in /etc/profile.d auf dem Server (raspian in meinem Fall) mit dieser Zeile darin:
[ "A${LC_CTYPE}" == "AUTF-8" ] && export LC_CTYPE="${LANG}"
Hoffe das hilft anderen...
Die grundlegende Frage ist
Meine primäre Frage ist, ist dies ein Fehler in MacOS? Oder besteht Linux zu Unrecht darauf, dass die Variable auf einen vollständig spezifizierten Gebietsschemanamen gesetzt werden muss?
und die POSIX-Seite für Umgebungsvariablen zeigt den Grund, warum andere die macOS-Konfiguration als falsch ansehen:
[XSI] Wenn Der Locale-Wert hat die Form:
language[_territory][.codeset]
es bezieht sich auf ein von der Implementierung bereitgestelltes Gebietsschema, bei dem die Einstellungen für Sprache, Gebiet und Zeichensatz implementierungdefiniert sind .
LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC und LC_TIME sind so definiert, dass sie einen zusätzlichen @-Feldmodifikator akzeptieren, der es dem Benutzer ermöglicht, eine bestimmte Instanz von Lokalisierungsdaten innerhalb einer einzelnen Kategorie auszuwählen (z. B. zum Auswählen des Wörterbuchs im Gegensatz zur Zeichenreihenfolge von Daten). Die Syntax für diese Umgebungsvariablen ist somit definiert als:
[language[_territory][.codeset][@modifier]]
Wenn ein Benutzer zum Beispiel auf Französisch mit dem System interagieren möchte, aber deutsche Textdateien sortieren muss, könnten LANG und LC_COLLATE wie folgt definiert werden:
LANG=Fr_FR
LC_COLLATE=De_DE
Dies könnte erweitert werden, um die Sortierung des Wörterbuchs (z. B.) durch Verwendung des @-Modifikatorfelds auszuwählen. zum Beispiel:
[email protected]
Eine Implementierung kann andere Formate unterstützen.
Wenn der Locale-Wert von der Implementierung nicht erkannt wird, ist das Verhalten nicht spezifiziert.
Das heißt, sie gehen davon aus, dass POSIX eine Syntax für die Locale-Einstellungen vorschreibt. Ein unachtsamer Leser würde annehmen, dass POSIX die zulässigen Formen für die Umgebungsvariablen so definiert, dass der codeset Der Wert ist optional und dient nicht als Ersatz für die Sprache . Aber dieses letzte „Mai“ öffnet ein Fass voller Würmer und segnet diesen Unterschied in der Interpretation. Apple kann tun, was es will, wenn es gültige Gebietsschemas bereitstellen möchte, die diesem Muster nicht genau folgen.
@tripleee schlug vor, dass die Seite zu Locale bessere Informationen liefert, aber das ist fast ausschließlich eine Diskussion der Locale-Definitionen und keine Anleitung für Interoperabilität (d. h. das angebliche Ziel von POSIX).
Keine der Seiten befasst sich mit Unterschieden in den verfügbaren Gebietsschemaeinstellungen (z. B. „.utf8“ im Vergleich zu „.UTF-8“). Diese sind implementierungsabhängig, wie auf der POSIX-Seite angegeben. Das lässt den Benutzern die einzige Lösung, selbst zu bestimmen, welche Locale-Einstellungen auf dem lokalen und entfernten System unterstützt werden, und (ssh-Verhalten hier) zu bestimmen, wie diese auf dem entfernten System "kompatibel" gesetzt werden.