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
