Des valeurs valides pour LC_CTYPE ?

Je ne suis pas entré dans les détails de qui a "vrai ou faux" - mais j'étais également ennuyé par le problème. Quelques solutions à cela :

• Côté serveur :
  • modifier/désactiver AcceptEnv LC_* en /etc/ssh/sshd
    • contre :il les définit sur la valeur par défaut du système
  • modifier .profile
    • Inconvénients :utilisateur unique
  • modifier /etc/bash* ou /etc/profile
    • contre :peut être inversé dans les mises à jour
• Côté client :
  • alias ssh="LC_CTYPE=\"${LANG}\" ssh" en .bashrc /.profile /whereEver
    • Inconvénients :utilisateur unique
  • comme côté serveur dans .bashrc /.profile ...
  • modifier/ajouter des paramètres dans Terminal
    • con :session entière, qu'elle soit locale ou distante

Donc, à la fin, j'ai fini par créer mac-locale-fix.sh en /etc/profile.d sur le serveur (raspian dans mon cas) avec cette ligne :

[ "A${LC_CTYPE}" == "AUTF-8" ] && export LC_CTYPE="${LANG}"

J'espère que cela aidera les autres...

La question de base est

Ma question principale est la suivante :est-ce un bogue dans MacOS ? Ou Linux a-t-il tort d'insister sur le fait que la variable doit être définie sur un nom de paramètre régional entièrement spécifié ?

et la page POSIX pour les variables d'environnement montre la raison pour laquelle d'autres considèrent la configuration macOS comme incorrecte :

[XSI] Si la valeur locale a la forme :

language[_territory][.codeset]

il fait référence à des paramètres régionaux fournis par l'implémentation, où les paramètres de langue, de territoire et de jeu de codes sont définis par l'implémentation .

LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , et LC_TIME sont définis pour accepter un champ supplémentaire @ modificateur, qui permet à l'utilisateur de sélectionner une instance spécifique de données de localisation dans une seule catégorie (par exemple, pour sélectionner le dictionnaire par opposition à l'ordre des caractères des données). La syntaxe de ces variables d'environnement est donc définie comme :

[language[_territory][.codeset][@modifier]]

Par exemple, si un utilisateur souhaite interagir avec le système en français, mais doit trier des fichiers texte en allemand, LANG et LC_COLLATE peuvent être définis comme :

LANG=Fr_FR
LC_COLLATE=De_DE

Cela pourrait être étendu pour sélectionner le classement du dictionnaire (par exemple) en utilisant le champ @modifier ; par exemple :

[email protected]

Une mise en œuvre peut prendre en charge d'autres formats.

Si la valeur locale n'est pas reconnue par l'implémentation, le comportement n'est pas spécifié.

Autrement dit, ils supposent que POSIX prescrit une syntaxe pour les paramètres régionaux. Un lecteur non averti supposerait que POSIX définit les formes autorisées pour les variables d'environnement afin que le jeu de codes la valeur est facultative et ne remplace pas la langue . Mais ce dernier "peut" ouvre une boîte de Pandore, bénissant en fait cette différence d'interprétation. Apple peut faire ce qu'il veut, s'il veut fournir des paramètres régionaux valides qui ne suivent pas exactement ce modèle.

@tripleee a suggéré que la page sur les paramètres régionaux donne de meilleures informations, mais il s'agit presque entièrement d'une discussion sur les définitions des paramètres régionaux plutôt que de fournir des conseils pour l'interopérabilité (c'est-à-dire l'objectif apparent de POSIX).

Aucune des deux pages ne traite des différences dans les paramètres régionaux disponibles (tels que ".utf8" par rapport à ".UTF-8"). Celles-ci dépendent de l'implémentation, comme indiqué sur la page POSIX. Cela laisse aux utilisateurs la seule solution étant de déterminer eux-mêmes quels paramètres régionaux sont pris en charge sur les systèmes locaux et distants, et (comportement ssh ici) de déterminer comment les définir sur le système distant "de manière compatible".