Bug 804

Summary:	Locale character encoding disobeyed on interactive session
Product:	Portable OpenSSH	Reporter:	Paweł Sakowski <pawel>
Component:	ssh	Assignee:	OpenSSH Bugzilla mailing list <openssh-bugs>
Status:	CLOSED WONTFIX
Severity:	enhancement	CC:	vincent-openssh
Priority:	P4
Version:	3.8p1
Hardware:	All
OS:	All

Description Paweł Sakowski 2004-02-29 07:54:14 AEDT

Take the following configuration:

local$ echo $LANG;locale charmap
pl_PL
UTF-8
local$ ssh user@remote
[...]
remote$ echo $LANG;locale charmap
pl_PL
ISO-8859-2

Now, if I invoke any locale-aware application on the remote machine (tar --help
is enough), any non-ASCII letter it sends over the net (try to) appear on my
console encoded in ISO-8859-2, that is, contrary to my terminal's settings.

Note that it's perfectly valid in glibc to pick any character encoding for the
locale one wants to use.

I believe that the client and the server should agree on a common interpretation
of the octets sent over the net (server->client or vice versa) as characters and
provide some sort of on-the-fly conversion.

Comment 1 Damien Miller 2004-03-03 09:29:12 AEDT

The protocol doesn't include transmission of environment variables. You should
set it at the remote end in .profile or similar.

Comment 2 Damien Miller 2004-04-14 12:24:20 AEST

Mass change of RESOLVED bugs to CLOSED

Comment 3 Vincent Lefevre 2008-08-13 23:50:47 AEST

I wonder why this bug has been closed as wontfix.

FYI, there has been some discussions about locale/charset negociation here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337041 (with a Cc to ietf-ssh at NetBSD.org).

Also, setting environment variables on the remote end is not always possible when a command is used. I've reported bug 1504 about that.