2009/9/22 Lapo Luchini: >> For example, a Windows filename "bäh" turns into "bŤh" in the C locale, >> while it shows up correctly with explicitly set ISO-8859-1 or CP1252. > > Uh? Doesn't seem so to me: if I create "bäh" in WindowsExplorer, then > open up an UTF-8 mintty console I have a consistent output with both > LANG=C and LANG=it_IT.UTF-8 (of course, since right now C is UTF-8): > > % LANG=C ls -l|egrep b.h > -rw-r--r-- 1 lapo None 0 Sep 22 09:53 bäh > % LANG=it_IT.UTF-8 ls -l|egrep b.h > -rw-r--r-- 1 lapo None 0 22 Sep 09:53 bäh
You've presumably got mintty set to UTF-8, hence mintty's output conversion turned ls's ISO-8859-1 "Ť" (i.e. "\xC3\xA4") into "ä". > So I'm not sure what do you mean with 'a Windows filename "bäh" turns > into "bŤh" in the C locale'... you mean that a script sees it as > 62C3A468 as opposed as 62E468? Or that actual "bŤh" is shown somewhere? Both. For the latter, try it in the default Cygwin console, without any locale variables set. > But OTOH as far as "not caring" goes, it sure can be a nice feature to > be retro-compatible in that single case Thanks. Unfortunately the "C" locale is rather important though, because that's what people will be using unless they go to the effort of finding out how to set a different locale. Andy -- 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
