Mail Archives: cygwin/2009/09/22/13:04:58
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 AT cygwin DOT 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
- Raw text -