(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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
