AcceptEnv LANG LC_* vs available locales

[Philipp Marek]

>> (As in, *let* the client send his settings, then have the shell's
>> startup phase run a helper application that edits the env vars as
>> necessary to achieve compatibility with the server's capabilities.)

That sounds the most sane way to me.


> And if the client says they want "zh_CN.UTF-16" but the server only
> knowns how to do "C" and "en_US.UTF-8", then what are you going to do,
> as just one example among a host of tricky combinations?  In fact,
> the only safe option in such a situation is to reject the connection.

Yeah, that might be one option.


> And even if a safe setting existed in every case, which it does not,
> it would be a complex and open-ended task to figure out what that 
> setting
> is on a given machine to be compatible with an arbitrary locale name
> received over the wire, since POSIX explicitly says that the meaning
> of locale names (apart from "C" and "POSIX") is implementation-defined.

Possibly.
Still, a 99.99% working solution should be easy enough --
and if your policy is stricter, than rejecting incompatible connections
(if even falling back to "C" doesn't work??) is possible.


> So for every operating system and every possible subset of locales that
> might be installed on a server, OpenSSH maintainers would have to 
> maintain

No.
Not the OpenSSH maintainers, but the packagers -
they know at least what their target machine understands.



> Sure, any magic scheme you might devise to achieve the above would
> likely work in many cases, so users would get trained into an utterly
> unsafe attitude of "locales just work with SSH" and stop thinking
> about it.  If the beast would then suddenly bite, it would bite all
> the deeper.

That's as it is right now, anyway.
Such a script would get _better_ compatibility than now.


> In conclusion, i think it is better to take a firm stand and say:
> 
>   It is purely the responsibility of the user to make sure that
>   the server locale and the client locale are compatible *before
>   connecting*.  Otherwise, all bets are off.

Well, how do I find out what's available without connecting?

If the server falls back to "C" (and tells me loudly upon connecting!!)
I at least have a chance to diagnose.


>   Ideally, use UTF-8
>   on both sides *and* make sure your xterm(1) runs in UTF-8 mode.

Yeah, that's the easy way.