Comment 5 for bug 394570

On Mon, Jan 02, 2006 at 05:29:40PM -0500, Bill Sommerfeld wrote:
> In response to later messages:
> > While setting LANG et al is indeed useful, it's not enough to make the
> > kernel's terminal driver do the right thing when erasing characters in
> > cooked mode. That's why the termios flag was invented.
>
> I think Nicolas was implying that a request from the client to use a
> UTF8 locale would cause the server to set up the pseudoterminal it
> creates/allocates/... appropriately for the requested locale. But
> that's perhaps at odds with the existing strategy within the protocol of
> making termios-level details visible on the wire.

I think I was a bit more explicit about this, but, yes, this would be a
hack, and very POSIX-specific (and I was explicit about that too). But
such a hack would also probably make most users happy :^/ at the expense
of elegance and code complexity for SSHv2 servers running on POSIXy
platforms.

SSHv2's pty negotiation could certainly improve in this regard, I don't
deny it!

But I suspect saying "UTF-8" is not enough here. What options are
there? Should the pty driver reject non-UTF-8 sequences? Should it
normalize? Pass input through raw? I suspect most users wouldn't want
much of a pty UTF-8 input mechanism as their clients, presumably, have a
decent UTF-8 input method already -- but then, maybe they don't.

I definitely think this should be a WG work item, if nothing else to
ensure it gets more eyeballs because I18N requires care.

Nico
--