Re: The C locale

[Lapo Luchini <lapo at lapo dot it>]

Mark J. Reed wrote:
> Yes, but it's working because you (1) lied about your locale (using C
> when your terminal is set to UTF-8) and (2) happen to have your
> terminal set to UTF-8, which is how Cygwin happens to be encoding the
> character.   It's a big accident and stops working if you were
> actually using a non-UTF-8 terminal and locale (hopefully matching
> ones).

I'm very sorry, but I still can't see your point... =(

It's true, "by accident" my terminal is using the more general
ASCII-compatible charset possible (that is, UTF-8) and Cygwin is
currently using that as a default as well, ok.
So LANG=C works essentially because my terminal uses THE SAME charset as
Cygwin uses by default (and not specifically because that's UTF-8).

But OTOH if LANG=C used CP1252 it would only work only if my terminal
"by accident" was using the very same CP1252 and would stop working if I
were using a non-CP1252 terminal and matching locale.
How is this a fundamentally different case?

In the first case I have to match my terminal, but I can see *any*
character really and never get any "surprise".
In the second case I can use default cmd.exe, but I get a crippled
output in many possible usecases.

The main reason I see for using CP1252 (or anything that's the default
CP, CP1252 is just an example) is that cygwin-in-cmd.exe would show the
*same* crippledness shown by the default native WindowsPrompt, so even
if very limited, the user would get the least surprise. And as far a
traffic on cygwin@cygwin.com goes, I see that's a VERY valid issue.

-- 
Lapo Luchini - http://lapo.it/

âPremature optimisation is the root of all evil in programming.â (C. A.
R. Hoare)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple