On Fri, Jun 07, 2013 at 01:20:22PM +0200, Martin Pitt wrote:
> Robbie and I discussed that again, and found a compromise for this
> which works around our ssh and sudo behaviour and should just do the
> wrong thing in rare corner cases now, unless of course people actually
> rely on the current behaviour of using the user locale:
Martin also demonstrated that in the multiuser use case, setting user
dotfiles should be sufficient to set the locale for each user correctly.
Passing the locale environment variables through ssh is problematic
because the locale may not be configured on the server. Given that the
user can set his own dotfiles on the server to meet this use case,
should ssh be passing through the locale environment variables at all?
> My preferred fix would be to ssh to simply stop passing (1host) at
> least if the remote system does not have that available. The very
> first time you press <tab> in the remote shell you'll get screen
> clutter by error messages, apt/dpkg will spit out a plethora of errors
> from perl, and the locale will not work and behave like C anyway.
> It's somewhat debatable if we want to pass (1host) if it is available
> on the server; I'd personally prefer not to because of our sudo
> behaviour, but I have no strong opionion about it, and good arguments
> can be made either way.
Do we need a bug on this?
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel