AcceptEnv LANG LC_* vs available locales
Jochen.Bern at binect.de
Tue May 3 07:00:11 AEST 2022
On 01.05.22 01:07, Thorsten Glaser wrote:
> On Sun, 1 May 2022, Jochen Bern wrote:
>> If that's your opinion, go ahead and implement it. Which my suggestion of a
>> server-side helper evaluating the client-side-set and server-side-available
> This could be… challenging. (There’s locale(1) -a, sure, but…)
Which part of it, a) getting the locally known locales, b) verifying
that they're indeed *operational* (OS knows it but your main app doesn't
support it), and/or c) selecting a compromise from them?
If a) and/or b), then that's already a problem in and of itself. What
good is locale support on just this *one* machine, not even doing any
remote connections, if the user has difficulties to pick the one he can
and wants to use?
(OK, we *are* talking about *human languages*. How many Germans, faced
with all "DE" locales being somehow missing/defunct, would know that
"Ripuarian" is actually a family of German dialects, and will likely be
mostly understandable to them ...)
c) is the problem we're trying to solve. Eggs, omelette. ;-)
> It also assumes locale support on both ends in the first place.
If the *client* lacks it, I would guess that $LANG and $LC_* are unset,
will be propagated empty to the server, and not offer any information on
the client and user whatsoever, with or without an attempt at negotiation.
If the *server* lacks it, there's no point in trying to select one on
the server side, anyway. The user will be faced with whatever passes as
the server's one and only locale, whether it's Greek to him or not.
>> I expect terminals to gravitate more and more towards implementing
>> it, increasing the pressure on the consortium to include two codepoints to
>> "shift to control" and "shift back" into its standards, laying the groundwork
>> of a *global* algorithm for terminals to tell control data from content.
> I highly doubt anything will change now, especially things that break
How would the Unicode Consortium allocating two codepoints for *this*
purpose be any *more* prone to "breaking compatibiliy" than the
expansion of the emoji list every dozen months or so already is?
Quite to the contrary, it would open the possibility to have the server
side modify its emitted data from
<prnChar> <prnChar> <termCtl> <prnChar> <prnChar> ...
<prnChar> <prnChar> <toCtl> <termCtl> <toText> <prnChar> <prnChar> ...
so that a terminal aware of the <toCtl> and <toText> characters could
recognize <termCtl> as a control sequence *even if the sequence is not a
proper one for this term at all*.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
More information about the openssh-unix-dev