© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
If locale-related environment variables were all that were handled by SendEnv/PAM then there would be no argument - we would happily allow SendEnv to take precedence. Unfortunately this is not the case and I generally think that env variables specified by a security subsystem (e.g. PAM) should "win". Given that an administrator must explicitly enable AcceptEnv anyway, this doesn't seem too unreasonable.
As a workaround, you can "rename" the locale variables at the client. E.g. by placing SSH_LANG=$LANG in your environment and SendEnv'ing SSH_LANG instead of LANG. At the sshd end, your shell initialisation can look for SSH_LANG and, if it is present, apply it - potentially overriding anything set by the admin.
Finally, if I understand correctly, there is little standardisation of the contents of LANG and LC_* so sending anything in them is bound to be fragile.