This is the mail archive of the
mailing list for the Cygwin project.
Re: bash and the current locale implementation
2009/10/1 Corinna Vinschen
> The idea is the the locale environment of the
> application determines how Cygwin internally converts multibyte to wide
> char and vice versa.
> At the start of every application, Cygwin now calls
> Âsetlocale (LC_CTYPE, "");
> Âsetlocale (LC_CTYPE, "C");
> The result is that Cygwin internally uses whatever the environment is
> set to, while the application uses the default "C" locale per POSIX.
> No application *has* to call setlocale (LC_ALL, "") for that to happen.
> However, *if* the application calls setlocale (LC_ALL, ""), because it
> is locale aware, it will just get the same conversion as the environment
> is set to anyway, and Cygwin and the application will use the same
> conversion functions.
So far, so good.
> An application using an explicit locale string like in `setlocale
> (LC_ALL, "en.UTF-8") is about to set something explicitely and ignore
> the environment settings.
Yep, and that's up to the application.
> See the modified list in
"- setlocale() will (probably) have no effects beyond what's expected in Linux."
> The charset of the console is
> determined by the environment setting of the current application.
Right, but I think it should be determined once at the start of a
process. If a process later changes its env variables, that's its own
business. It should not have an effect on filenames or console I/O,
because it wouldn't on Linux either.
The assumption on Linux is that the environment variables at process
startup tell an application what encoding is used in filenames and in
its terminal. An application might be calling setlocale() with
different charsets a lot of times, e.g. to convert between different
encodings, but it would not expect that to have an effect on filenames
or the terminal.