Package: ssh Version: 1:3.8.1p1-8 Severity: wishlist I recently started using the en_US.UTF-8 locale. I was surprised that when I logged in from one Debian system with LANG=en_US.UTF-8, to another Debian system that supports this locale, that the LANG variable was empty. This causes a problem with remote applications, because they don't know the encoding being used by the terminal.
I would think this issue would come up often, but my web searches didn't reveal much. The behavior I would expect is that locale environment variables would be preserved, as long as the remote system supports that locale. If not, a warning should perhaps be printed. Andrew -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages ssh depends on: ii adduser 3.59 Add and remove users and groups ii debconf 1.4.30 Debian configuration management sy ii dpkg 1.10.23 Package maintenance system for Deb ii libc6 2.3.2.ds1-15 GNU C Library: Shared libraries an ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libssl0.9.7 0.9.7d-5 SSL shared libraries ii libwrap0 7.6.dbs-5 Wietse Venema's TCP wrappers libra ii zlib1g 1:1.2.1.1-5 compression library - runtime -- debconf information: ssh/insecure_rshd: ssh/ssh2_keys_merged: ssh/user_environment_tell: * ssh/forward_warning: ssh/insecure_telnetd: ssh/new_config: true * ssh/use_old_init_script: true * ssh/protocol2_only: true ssh/encrypted_host_key_but_no_keygen: * ssh/run_sshd: true * ssh/SUID_client: false
