[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Accessing the environment's locale encoding settings
From: |
Mike Gran |
Subject: |
Re: Accessing the environment's locale encoding settings |
Date: |
Sun, 20 Nov 2011 11:44:10 -0800 (PST) |
>From: Ludovic Courtès <address@hidden>
>>Bruno Haible <address@hidden> skribis:
>
>> No, I'm suggesting to let the Scheme code know that is it using the user's
>> locale.
>>
>> Yes, this is a backward-incompatible change, so probably you won't want to
>> do it on the guile 2.0.x branch, and you will want to advertise it in the
>> release notes or NEWS file.
>
>I’m now convinced that an implicit setlocale(LC_ALL, "") is the right
>thing for ‘master’.
>
>For 2.0, though, this brings us back to the hack I proposed at the
>beginning of this thread, namely trying to honor LC_CTYPE without
>actually calling setlocale, so that command-line arguments are suitably
>converted.
I probably shouldn't express an opinion on this, since my SLOC count is so
low these days, but, I'll do it anyway. ;-)
As I am snarkily wont to say, everyone wants Unicode but no one really uses
it. It you were to make that change in 2.0.x, I can almost guarantee that
no one will be adversely affected. 2.0.x programs that are already trying to
use locale will just have a redundant call to setlocale. 2.0.x programs that
ignore locale are de facto C locale anyway. The scripts that would be at risk
are those that try to read binary data as string input instead of binary input.
Here's a suggestion. One could add an option to the guile interpreter's command
line args (--locale=ARG perhaps) that has the effect of calling
setlocale(LC_ALL,"ARG") first thing. If --locale is called with no ARG
specified, it would call to setlocale(LC_ALL, "").
That way, people could start future-proofing their code now by adding
--locale or --locale=C to the top of their scripts. For now, the default can
be, in effect, --locale=C and for 2.2 it can be --locale.
That would slightly complicate getopt processing, since you'd have to scan for
the --locale before processing other getopt arguments.
-Mike
- Accessing the environment's locale encoding settings, Ludovic Courtès, 2011/11/15
- Re: Accessing the environment's locale encoding settings, Bruno Haible, 2011/11/15
- Re: Accessing the environment's locale encoding settings, Bruno Haible, 2011/11/20
- Re: Accessing the environment's locale encoding settings, Ludovic Courtès, 2011/11/20
- Re: Accessing the environment's locale encoding settings,
Mike Gran <=
- Re: Accessing the environment's locale encoding settings, Ludovic Courtès, 2011/11/23
- Re: Accessing the environment's locale encoding settings, Mike Gran, 2011/11/23
- Re: Accessing the environment's locale encoding settings, Peter Brett, 2011/11/24
- Re: Accessing the environment's locale encoding settings, Mark H Weaver, 2011/11/24
- Re: Accessing the environment's locale encoding settings, Bruno Haible, 2011/11/20