[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Remote filenames with non-ASCII chars and LC_ALL=C

From: Michael Albinus
Subject: Re: Remote filenames with non-ASCII chars and LC_ALL=C
Date: Fri, 01 Jan 2010 16:49:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

Øyvind Stegard <address@hidden> writes:

> Hello TRAMP developers,


> I believe the default setting of "LC_ALL=C" in the
> `tramp-remote-process-environment' variable is causing problems for
> remote filenames with non-ASCII characters in them: Remote shell
> commands (at least 'ls') will simply replace all such chars with
> question marks when run under C locale with output to a terminal. I work
> primarily on hosts with UTF-8 as default locale encoding, but
> occasionally I have to edit remote files on systems which default to
> ISO-8859-1. The "LC_ALL=C" setting seems to break all non-ASCII setups,
> even when both local and remote system are using the same encoding (for
> instance local UTF-8 <--> remote UTF-8).
> IIRC, tramp worked properly with non-ASCII filenames in Emacs 22 by
> default, if both systems used the same locale encoding. This is not true
> for Emacs 23, that's why I'm reporting it here. Simply setting "LC_ALL="
> (explicitly unset the var) in the default remote process environment
> list makes things work again. (Curiously though, it wasn't enough to
> remove it from the list, I had to explicitly unset it. Maybe it's
> hardcoded somewhere else in tramp.el code as well.) I realise the
> variable is meant to be customized, so whatever "LC_ALL=C" fixes must be
> weighed against the fact that it breaks non-ASCII chars in filenames
> when it's there by default.

Recently, there was a discussion about the same topic. See

We will try to apply LC_MESSAGES and LC_NUMERIC selectively. However,
givent that there is already feature freeze of Emacs 23.2, I cannot
promise we will be able to put it into that release. It depends, whether
the needed changes are small enough to ensure that there won't be
collateral damages.

> Thanks,
> Øyvind Stegard

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]