Mail Archives: cygwin/2009/06/03/11:04:16
Hi.
How about the addition of the setting of the locale environment
variable (like LANG) to the Cygwin installer?
2009/6/3 Corinna Vinschen <corinna-cygwin AT cygwin DOT com>:
> On Jun =A03 09:18, Edward Lam wrote:
>> Corinna Vinschen wrote:
>>> The question is, what do you expect? =A0[...]
>> [...]
>> Wikipedia has several suggestions on how to handle invalid UTF-8 byte
>> sequences (http://en.wikipedia.org/wiki/UTF-8). Personally, I favor the
>> rule that uses the replacement character.
>
> Chris implemented using the invalid code point solution. =A0The discussion
> in http://www.mail-archive.com/linux-utf8 AT nl DOT linux DOT org/msg00080.html
> supports this solution. =A0What's missing so far is the way back, from
> an invalid single second half of a surrogate pair in the 0xDCxx range
> back to the correct byte value. =A0I'm just looking into that.
>
>> > How is anybody supposed to know that the file which consists
>> > of the single byte 0xa9 has *any* meaning at all? =A0Why should it be
>> > the copyright sign, of all things?
>>
>> What I was attempting to do was to have NO conversion. In the
>> real case that I into this, the "bug.exe" was the one to properly
>> interpret what the byte 0xA9 meant from the command line. Yes, I know
>> there are several workarounds.
>
> The command line is always converted to UTF-16 when calling a native
> Win32 application. =A0If we don't do it (because we call CreateProcessA),
> Windows would do it. =A0As matters stand, we have to convert ourselves,
> because we must call CreateProcessW. =A0Either way, the problem persists.
> We just don't know what the correct conversion is for the given input.
> We have to rely on a correct setting of $LC_ALL/$LANG/$LC_CTYPE.
>
>>> If we default to the ANSI codepage, you will have the same problem,
>>> just upside down. =A0In both cases you will have even more problems if
>>> you start using characters not available in your default codepage.
>>
>> This is where I disagreed with Alexey. What we're really arguing here is
>> whether which default will run into the least problems for the most
>> common usage. This is subjective of course.
>
> Definitely. =A0The "right" solution is always only right for a given value
> of right. =A0What if the user has set LANG to, say, ja_JP.eucJP? =A0That
> user of course expects that the stuff on the command line is converted
> to UTF-16 using the eucJP encoding. =A0Everything else would just be very
> surprising.
>
> What's left as questionable is the LANG=3DC default case. =A0Due to the
> discussion from the last month we now use UTF-8 as default encoding,
> because it's the only encoding which covers all (valid) characters.
> Sure, we could also convert the command line using the current ANSI
> codepage as Windows does it when calling CreateProcessA in this case.
>
> Maybe we should do that for testing? =A0Anybody having a strong opinion
> here?
>
>
> Corinna
>
> --
> Corinna Vinschen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Please, send mails re=
garding Cygwin to
> Cygwin Project Co-Leader =A0 =A0 =A0 =A0 =A0cygwin AT cygwin DOT com
> Red Hat
>
> --
> Unsubscribe info: =A0 =A0 =A0http://cygwin.com/ml/#unsubscribe-simple
> Problem reports: =A0 =A0 =A0 http://cygwin.com/problems.html
> Documentation: =A0 =A0 =A0 =A0 http://cygwin.com/docs.html
> FAQ: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://cygwin.com/faq/
>
>
--=20
IWAMURO Motnori <http://vmi.jp/>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -