Re: IUTF8 pseudo-terminal mode

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Mon, May 12, 2008 at 10:18:50AM +0100, Colin Watson wrote:
> On Mon, May 12, 2008 at 10:07:47AM +0200, Vincent Lefevre wrote:
> 
> OpenSSH, as configured in Debian, does this too.

Good!

> Locale names are indeed opaque as far as POSIX is concerned, so there's

Well, no, there's a bit of rhyme and reason to [some] POSIX locale names
-- it just isn't used for all locale names.  But point taken: to
implement a decent locale negotiation protocol one would need an API by
which to ask questions about a locale name (what charset, what language,
what collation, ...).

> no portable way to pick them apart. But even if locale names are in
> principle identical (i.e. client and server running the same release of
> the same operating system), there's a further problem. With glibc,
> locale definitions are quite large (thus inconvenient to distribute in
> pre-generated form) and take some time to generate, so it's fairly
> common for distributions to set things up so that you only generate the
> locale definitions you need. The locale you're using on the client may
> simply not exist on the server.

Right.  Add in the fact that users can, and often do speak/read multiple
languages, and there's a real need to negotiate locales.  SSHv2 already
has a language negotiation facility for localization of server messages
intended for the user; it's a start.

So, given a decent locale API one could take the charset of the locale
requested by the user and the languages negotiated for the session, and
search for a best match locale on the server-side.

But still, remotely setting a channel's LC_*/LANG is a pretty poor way
of dealing with this problem.  For one, it isn't documented in any RFC,
so you can't expect implementors to know what to do with it.

> This is compounded by the fact that there is no equivalent of "C" for
> UTF-8 in glibc: that is, there's no way to say "I just want a basically

Nor in Solaris.

> > Well, localization of messages and date formats are just a user choice.
> > If they are different on the remote side, this isn't really a problem.

If I can't read the messages then they aren't helpful, but yeah, at the
very least they should display properly.

Nico
--