Bug#337041: IUTF8 pseudo-terminal mode
On Mon, May 12, 2008 at 10:07:47AM +0200, Vincent Lefevre wrote:
> On 2008-05-11 21:00:55 -0500, Nicolas Williams wrote:
> > SunSSH 1.1 does (by having the client set per-channel LANG/LC_*
> > environment variables).
>
> I meant in a way that always works in practice.
It tends to, though only by dint of luck.
> > It's less than perfect: the client has no idea what a client-side
> > locale maps to on the server side.
>
> Yes, that's the problem: it's not always possible to rebuild a correct
> LC_CTYPE on the remote side, e.g. if LC_CTYPE is "en_US", one doesn't
> have information about the charset on the remote side.
There should be a way. SSHv2 already negotiates languages. A
negotiation of charsets per-channel wouldn't be too difficult to add.
> > Also, it's not just character sets that matter, but language for
> > localization of messages, date formats, etc...
>
> Well, localization of messages and date formats are just a user choice.
Yes, but the user doesn't want to be making that choice all the time.
What if the user reads three languages and doesn't know which the remote
server has localizations for? What if the user doesn't have "dot files"
on the server? It'd be nice if the client and server could just settle
on a locale that meets the user's needs with no additional input from
the user.
> If they are different on the remote side, this isn't really a problem.
Yes it is.
> Concerning the character set, the remote one must be compatible with
> the local one, at least when a terminal is used (ditto for the IUTF8
> pseudo-terminal mode). Otherwise the user can't view or edit non-ASCII
> characters correctly.
I agree with the first point, but not necessarily with the second (the
client can always put the local terminal into raw mode and let the
server-side IUTF8 mode take over).
Nico
--
Reply to: