Início / unix / Perguntas / 503110
Accepted
tripleee
Asked: 2019-02-27 03:09:47 +0800 CST

Valores válidos para LC_CTYPE?

  • 772

Encontrei várias perguntas em vários fóruns em que usuários de Mac reclamam de localeerros ao fazer login em sistemas Linux por SSH, reclamando que a LC_CTYPE=UTF-8configuração está incorreta.

Com mais detalhes, o shell no MacOS parece definir esse valor e, em seguida, (se você tiver a opção ativada no Terminal ou etc.), suas LC_*variáveis ​​locais serão exportadas para o sistema remoto quando você usar o SSH.

O Linux insiste que LC_CTYPEprecisa ser definido para uma localidade válida (às vezes você pode corrigir isso localegencomo administrador no sistema Linux), mas UTF-8não é uma localidade em primeiro lugar.

Minha pergunta principal é, isso é um bug no MacOS? Ou o Linux está errado ao insistir que a variável precisa ser definida para um nome de localidade totalmente especificado?

Secundariamente, para poder argumentar qual é a correta e por quê, onde isso é especificado?

Em terceiro lugar, há algo que esses usuários de Mac (inclusive eu) poderiam ou deveriam fazer diferente?

A solução óbvia é colocar algo como

LC_CTYPE=en_US.UTF-8

no seu .bash_profile, mas isso obviamente só resolve para sua conta pessoal e codifica um valor que pode ou não concordar com suas outras localeconfigurações.

linux osx

2 respostas

  1. Não entrei nos detalhes de quem está "certo ou errado" - mas fiquei igualmente incomodado com o problema. Algumas soluções para isso:

    • Lado do servidor:
      • alterar/desativar AcceptEnv LC_*em/etc/ssh/sshd
        • contras: ele os define para o padrão do sistema
      • editar.profile
        • contras: usuário único
      • editar /etc/bash*ou/etc/profile
        • contras: pode ser revertido em atualizações
    • Lado do cliente:
      • alias ssh="LC_CTYPE=\"${LANG}\" ssh"em .bashrc/// .profileonde sempre
        • contras: usuário único
      • igual ao lado do servidor em .bashrc/ .profile...
      • alterar/adicionar configurações no Terminal
        • contra: sessão inteira, seja local ou remota

    Então, no final, acabei criando mac-locale-fix.shno /etc/profile.dservidor (raspian no meu caso) com esta linha:

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

    Espero que isso ajude os outros...

    • 3
  2. Best Answer

    A questão básica é

    Minha pergunta principal é, isso é um bug no MacOS? Ou o Linux está errado ao insistir que a variável precisa ser definida para um nome de localidade totalmente especificado?

    e a página POSIX para variáveis ​​de ambiente mostra o motivo pelo qual outras pessoas veem a configuração do macOS como incorreta:

    [XSI] Se o valor de localidade tiver o formato:

    language[_territory][.codeset]

    refere-se a uma localidade fornecida pela implementação, em que as configurações de idioma, território e conjunto de códigos são definidas pela implementação .

    LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERICe LC_TIMEsão definidos para aceitar um modificador de campo @ adicional, que permite ao usuário selecionar uma instância específica de dados de localização dentro de uma única categoria (por exemplo, para selecionar o dicionário em oposição à ordenação de caracteres dos dados). A sintaxe para essas variáveis ​​de ambiente é assim definida como:

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

    Por exemplo, se um usuário quiser interagir com o sistema em francês, mas precisar classificar arquivos de texto em alemão, LANG e LC_COLLATE podem ser definidos como:

    LANG=Fr_FR
LC_COLLATE=De_DE

    Isso pode ser estendido para selecionar o agrupamento do dicionário (digamos) pelo uso do campo modificador @; por exemplo:

    LC_COLLATE=De_DE@dict

    Uma implementação pode suportar outros formatos.

    Se o valor de localidade não for reconhecido pela implementação, o comportamento não será especificado.

    Ou seja, eles assumem que POSIX prescreve uma sintaxe para as configurações de localidade. Um leitor desavisado assumiria que o POSIX define as formas permitidas para as variáveis ​​de ambiente para que o valor do conjunto de código seja opcional e não aja como um substituto para a linguagem . Mas esse último "pode" abre uma lata de vermes, de fato abençoando essa diferença de interpretação. A Apple pode fazer o que quiser, se quiser fornecer localidades válidas que não sigam exatamente esse padrão.

    @tripleee sugeriu que a página sobre Locale fornece informações melhores, mas isso é quase inteiramente uma discussão das definições de localidade, em vez de fornecer orientação para interoperabilidade (ou seja, o objetivo ostensivo do POSIX).

    Nenhuma das páginas aborda as diferenças nas configurações de localidade disponíveis (como ".utf8" versus ".UTF-8"). Esses são dependentes da implementação, conforme observado na página POSIX. Isso deixa os usuários com a única solução de determinar por si mesmos quais configurações de localidade são suportadas nos sistemas local e remoto e (comportamento ssh aqui) determinar como definir essas configurações no sistema remoto "compatíveis".

    • 2

relate perguntas