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 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
