[ ⏰ 20/03/2015 05:54 ] [ ✎ Christoph Anton Mitterer ] >> > That was the only clean way to pass the charmap. > Which software is using that variable? > > > None, except Vincent's own setup _as a user_. But you know, there are Linux users out there that are not administrators of all the machines they use. The openssh and pam combination has a long standing bug : it does not allow to pass around the settings for language and charmap, if pam sets defaults. Remark that they are not really defaults for ssh, because contrarily to (almost?) all other pam-using applications, openssh passes around the AcceptEnv variables and then uses PAM over it. As openssh upstream does not care about this issue (my opinion is that the developers do not use various locales and charmaps in their environment), the only convenient way when you do not control your ssh daemon is to pass around an environment setting (I suppose that's what Vincent Lefevre used LC_CHARMAP for), and tinker with your initial setup (profile or bashrc or zshrc or whateverrc) so that the locales are correctly adjusted. I guess a [ -n "$LC_CHARMAP" ] && LANG="$LC_CHARMAP" is enough for that. For a time, I had a patch around fixing the bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408029). When it stopped working, I lost interest : our guests just get French and Unicode settings whenever they ssh to our machines, whether they speak French or not, whether they are in UTF-8 charmap or not. But that still is a bug. By ignoring this bug in debian (8 years old), and breaking the workarounds, Debian makes it harder for users. That's a choice that can be made, but I would like to know if there is a single package out there using a LC_* variable that is not a standard LC_* variable and thus susceptible to hacking that way. The cost/gain balance does not look positive to me, but I'm not the maintainer. Sincerely yours, JC Dubacq
Attachment:
signature.asc
Description: OpenPGP digital signature