On 09 Oct, 2010,at 02:07 PM, Antoine Pitrou <report@bugs.python.org> wrote:
Antoine Pitrou <pitrou@free.fr> added the comment:
> For the command line, it would mean that we
> introduced a new encoding: "command line encoding", which will be utf-8 on
> OSX.
Or more generally "environment encoding", if it's also used for env
vars. This could solve the subprocess issue neatly.
Note that the command-line and environment encoding on OSX is generally UTF-8, even if that is not always reflected in the locale settings.
On recent OSX releases LANG will be set to a UTF-8 aware locale ("en_US.UTF-8" on my machine) when you start a shell using Terminal.app.
The correct locale environment variables are AFAIK not set in two important situations: on OSX 10.4 and when running code from an application bundle, in both cases the environment/command-line encoding should be treated as UTF-8.
There is one reason for not wanting to assume that the encoding is always UTF-8: the user might access the system from a non-UTF8 terminal (such as when logging in with an SSH session from a system not using UTF-8, or using an alternate terminal application). IMHO these are minor enough use-cases that we could just enforce that the encoding is UTF-8 on OSX.
That would ensure that the filesystem encoding and environment/command-line encoding are consistent and we'd no longer run into the problem that triggered this issue.
Ronald
----------
_______________________________________
Python tracker <report@bugs.python.org>
<
http://bugs.python.org/issue9992>
_______________________________________