Comment 13 for bug 394570

On 2008-05-12 09:35:46 -0500, Nicolas Williams wrote:
> 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?

There's also the problem that if the user shell is bash, the .bashrc
(or .bash_profile) isn't always read (fortunately, Debian's bash doesn't
have this problem).

> 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 full locale negociation could be added to SSH, this would be great.

> > If they are different on the remote side, this isn't really a problem.
>
> Yes it is.

Well, less than the charset problem. BTW, I generally want some of my
locales to be defined locally on each machine. For instance, I use
LC_TIME=en_DK (to have ISO-8601 dates) under Linux, but this locale
doesn't exist under Mac OS X; worse than that, if I try to use it
under Mac OS X, it makes a terrible mess.

> > 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).

I don't understand, or is it just that this isn't implemented in
OpenSSH yet?

--
Vincent Lefèvre <email address hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)