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.