Valori validi per LC_CTYPE?

Non sono entrato nei dettagli di chi ha "ragione o torto", ma ero ugualmente infastidito dal problema. Alcune soluzioni a questo:

• Lato server:
  • modifica/disabilita AcceptEnv LC_* in /etc/ssh/sshd
    • svantaggi:li imposta come predefiniti di sistema
  • modifica .profile
    • contro:singolo utente
  • modifica /etc/bash* o /etc/profile
    • contro:può essere annullato negli aggiornamenti
• Lato client:
  • alias ssh="LC_CTYPE=\"${LANG}\" ssh" in .bashrc /.profile /doveEver
    • contro:singolo utente
  • uguale a lato server in .bashrc /.profile ...
  • modifica/aggiungi impostazioni nel Terminale
    • con:intera sessione, locale o remota

Quindi, alla fine ho finito per creare mac-locale-fix.sh in /etc/profile.d sul server (raspian nel mio caso) con questa riga:

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

Spero che questo aiuti gli altri...

La domanda di base è

La mia domanda principale è:si tratta di un bug in MacOS? Oppure Linux ha torto a insistere sul fatto che la variabile deve essere impostata su un nome locale completamente specificato?

e la pagina POSIX per le variabili di ambiente mostra il motivo per cui altri vedono la configurazione di macOS come errata:

[XSI] Se il valore locale ha la forma:

language[_territory][.codeset]

si riferisce a un'impostazione locale fornita dall'implementazione, in cui le impostazioni di lingua, territorio e codeset sono definite dall'implementazione .

LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC e LC_TIME sono definiti per accettare un ulteriore modificatore di campo @, che consente all'utente di selezionare un'istanza specifica di dati di localizzazione all'interno di una singola categoria (ad esempio, per selezionare il dizionario anziché l'ordinamento dei caratteri dei dati). La sintassi per queste variabili d'ambiente è quindi definita come:

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

Ad esempio, se un utente desidera interagire con il sistema in francese, ma deve ordinare i file di testo in tedesco, LANG e LC_COLLATE potrebbero essere definiti come:

LANG=Fr_FR
LC_COLLATE=De_DE

Questo potrebbe essere esteso per selezionare la collazione del dizionario (diciamo) usando il campo modificatore @; ad esempio:

[email protected]

Un'implementazione può supportare altri formati.

Se il valore locale non viene riconosciuto dall'implementazione, il comportamento non è specificato.

Vale a dire, presumono che POSIX prescriva una sintassi per le impostazioni locali. Un lettore incauto presumerebbe che POSIX definisca le forme consentite per le variabili di ambiente in modo che il codeset il valore è facoltativo e non sostituisce la lingua . Ma quell'ultimo "può" apre un barattolo di vermi, in effetti benedicendo questa differenza di interpretazione. Apple può fare quello che vuole, se vuole fornire locali validi che non seguano esattamente quel modello.

@tripleee ha suggerito che la pagina sulle impostazioni locali fornisca informazioni migliori, ma si tratta quasi interamente di una discussione sulle definizioni delle impostazioni locali piuttosto che di una guida per l'interoperabilità (vale a dire, l'obiettivo apparente di POSIX).

Nessuna delle due pagine affronta le differenze nelle impostazioni locali disponibili (come ".utf8" rispetto a ".UTF-8"). Quelli dipendono dall'implementazione, come indicato nella pagina POSIX. Ciò lascia agli utenti l'unica soluzione di determinare autonomamente quali impostazioni locali sono supportate sui sistemi locale e remoto e (comportamento ssh qui) determinare come impostarle sul sistema remoto "in modo compatibile".