No entré en los detalles de quién está "bien o mal", pero el problema me molestó igualmente. Algunas soluciones a esto:
- Lado del servidor:
- cambiar/deshabilitar
AcceptEnv LC_*
en/etc/ssh/sshd
- contras:los establece en el sistema predeterminado
- editar
.profile
- contras:usuario único
- editar
/etc/bash*
o/etc/profile
- desventajas:puede revertirse en las actualizaciones
- cambiar/deshabilitar
- Lado del cliente:
alias ssh="LC_CTYPE=\"${LANG}\" ssh"
en.bashrc
/.profile
/donde quiera- contras:usuario único
- igual que en el lado del servidor en
.bashrc
/.profile
... - cambiar/agregar configuraciones en Terminal
- con:toda la sesión, ya sea local o remota
Entonces, al final terminé creando mac-locale-fix.sh
en /etc/profile.d
en el servidor (raspian en mi caso) con esta línea:
[ "A${LC_CTYPE}" == "AUTF-8" ] && export LC_CTYPE="${LANG}"
Espero que esto ayude a otros...
La pregunta básica es
Mi pregunta principal es, ¿es esto un error en MacOS? ¿O Linux se equivoca al insistir en que la variable debe establecerse en un nombre de configuración regional completamente especificado?
y la página POSIX para variables de entorno muestra la razón por la que otros ven la configuración de macOS como incorrecta:
[XSI] Si el valor local tiene la forma:
language[_territory][.codeset]
se refiere a una configuración regional proporcionada por la implementación, donde la configuración del idioma, el territorio y el conjunto de códigos están definidos por la implementación .
LC_COLLATE
, LC_CTYPE
, LC_MESSAGES
, LC_MONETARY
, LC_NUMERIC
y LC_TIME
están definidos para aceptar un campo @ modificador adicional, que permite al usuario seleccionar una instancia específica de datos de localización dentro de una sola categoría (por ejemplo, para seleccionar el diccionario en lugar de la ordenación de caracteres de los datos). La sintaxis de estas variables de entorno se define así:
[language[_territory][.codeset][@modifier]]
Por ejemplo, si un usuario quisiera interactuar con el sistema en francés, pero necesita ordenar archivos de texto en alemán, LANG y LC_COLLATE podrían definirse como:
LANG=Fr_FR
LC_COLLATE=De_DE
Esto podría extenderse para seleccionar la intercalación de diccionarios (digamos) mediante el uso del campo modificador @; por ejemplo:
example@unixlinux.online
Una implementación puede admitir otros formatos.
Si la implementación no reconoce el valor de configuración regional, el comportamiento no se especifica.
Es decir, asumen que POSIX prescribe una sintaxis para la configuración local. Un lector incauto supondría que POSIX define las formas permitidas para las variables de entorno de modo que el conjunto de códigos el valor es opcional y no actúa como reemplazo del idioma . Pero ese último "puede" abre una lata de gusanos, en efecto, bendice esta diferencia de interpretación. Apple puede hacer lo que quiera, si quiere proporcionar configuraciones regionales válidas que no sigan exactamente ese patrón.
@tripleee sugirió que la página sobre Configuración regional brinde mejor información, pero eso es casi en su totalidad una discusión sobre las definiciones de configuración regional en lugar de proporcionar una guía para la interoperabilidad. (es decir, el objetivo aparente de POSIX).
Ninguna página aborda las diferencias en la configuración regional disponible (como ".utf8" frente a ".UTF-8"). Esos dependen de la implementación, como se indica en la página POSIX. Eso deja a los usuarios con la única solución que es determinar por sí mismos qué configuraciones locales son compatibles con los sistemas locales y remotos, y (comportamiento ssh aquí) determinar cómo configurarlas en el sistema remoto de manera "compatible".