Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On 06/03/2009, Christopher Faylor wrote: If you really must know, I was waiting for Corinna to return from vacation before advertising the fix because I wanted her to look at it first before it was exposed to sound and fury of the cygwin mailing list. Looks like you gotyour wish. ;-) -- Larry

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Wed, Jun 03, 2009 at 01:19:45PM -0400, Edward Lam wrote: >Christopher Faylor wrote: >>As Corinna said above: "Chris implemented using the invalid code point >>solution" >> >>That's what is in Cygwin's CVS and in the latest snapshot. > >I see, you silently committed a fix while this discussion wa

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Wed, Jun 3, 2009 at 6:27 PM, Corinna Vinschen wrote: > What's left as questionable is the LANG=C default case.  Due 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 t

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Christopher Faylor wrote: As Corinna said above: "Chris implemented using the invalid code point solution" That's what is in Cygwin's CVS and in the latest snapshot. I see, you silently committed a fix while this discussion was ongoing? http://www.cygwin.com/snapshots/winsup-changelog-2009053

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Wed, Jun 03, 2009 at 12:55:57PM -0400, Edward Lam wrote: >Corinna Vinschen wrote: >> On Jun 3 12:02, Christopher Faylor wrote: >>> On Wed, Jun 03, 2009 at 04:27:55PM +0200, Corinna Vinschen wrote: On Jun 3 09:18, Edward Lam wrote: > Corinna Vinschen wrote: >> The question is, what

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

IWAMURO Motonori wrote: And, I think that UTF-8 is best solution when the setting of LC_CTYPE category is C. 2009/6/4 IWAMURO Motonori : I think that this problem is caused by missing setting the locale environment variable. Therefore, I think that the problem can be solved by compelling the se

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Corinna Vinschen wrote: On Jun 3 12:02, Christopher Faylor wrote: On Wed, Jun 03, 2009 at 04:27:55PM +0200, Corinna Vinschen wrote: On Jun 3 09:18, Edward Lam wrote: Corinna Vinschen wrote: The question is, what do you expect? [...] [...] Wikipedia has several suggestions on how to handle

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

And, I think that UTF-8 is best solution when the setting of LC_CTYPE category is C. 2009/6/4 IWAMURO Motonori : > I think that this problem is caused by missing setting the locale > environment variable. > Therefore, I think that the problem can be solved by compelling the > setting with setup.ex

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

I think that this problem is caused by missing setting the locale environment variable. Therefore, I think that the problem can be solved by compelling the setting with setup.exe. 2009/6/4 Corinna Vinschen : > > http://cygwin.com/acronyms/#PCYMTNQREAIYR > http://cygwin.com/acronyms/#TOFU > > On Ju

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Jun 3 18:12, Corinna Vinschen wrote: > On Jun 3 12:01, Edward Lam wrote: > > Corinna Vinschen wrote: > >> No. I'm suggesting to convert the command line always using the default > >> ANSI codepage, same as Windows when calling CreateProcessA. This only > >> affects non-Cygwin processes anywa

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Jun 3 12:01, Edward Lam wrote: > Corinna Vinschen wrote: >> No. I'm suggesting to convert the command line always using the default >> ANSI codepage, same as Windows when calling CreateProcessA. This only >> affects non-Cygwin processes anyway since Cygwin uses another mechanism >> to send th

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Jun 3 12:02, Christopher Faylor wrote: > On Wed, Jun 03, 2009 at 04:27:55PM +0200, Corinna Vinschen wrote: > >On Jun 3 09:18, Edward Lam wrote: > >> Corinna Vinschen wrote: > >>> The question is, what do you expect? [...] > >> [...] > >> Wikipedia has several suggestions on how to handle inva

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Wed, Jun 03, 2009 at 04:27:55PM +0200, Corinna Vinschen wrote: >On Jun 3 09:18, Edward Lam wrote: >> Corinna Vinschen wrote: >>> The question is, what do you expect? [...] >> [...] >> Wikipedia has several suggestions on how to handle invalid UTF-8 byte >> sequences (http://en.wikipedia.org/

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Corinna Vinschen wrote: No. I'm suggesting to convert the command line always using the default ANSI codepage, same as Windows when calling CreateProcessA. This only affects non-Cygwin processes anyway since Cygwin uses another mechanism to send the command line arguments to the child process.

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

http://cygwin.com/acronyms/#PCYMTNQREAIYR http://cygwin.com/acronyms/#TOFU On Jun 4 00:03, IWAMURO Motonori wrote: > 2009/6/3 Corinna Vinschen > > What's left as questionable is the LANG=C default case.  Due to the > > discussion from the last month we now use UTF-8 as default encoding, > > beca

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Jun 3 10:43, Edward Lam wrote: > Corinna Vinschen wrote: >> What's left as questionable is the LANG=C default case. Due 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 c

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Hi. How about the addition of the setting of the locale environment variable (like LANG) to the Cygwin installer? 2009/6/3 Corinna Vinschen : > On Jun  3 09:18, Edward Lam wrote: >> Corinna Vinschen wrote: >>> The question is, what do you expect?  [...] >> [...] >> Wikipedia has several suggestio

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Corinna Vinschen wrote: What's left as questionable is the LANG=C default case. Due 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

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Jun 3 09:18, Edward Lam wrote: > Corinna Vinschen wrote: >> The question is, what do you expect? [...] > [...] > 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

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Corinna Vinschen wrote: On May 29 17:21, Edward Lam wrote: I think the problem I'm running into is: - I give cygwin 1.7's bash a string that is in my system default code page. - cygwin 1.7 thinks the string is actually UTF-8 and tries to convert it as UTF-8 into UTF-16, resulting in a truncated

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On May 29 17:21, Edward Lam wrote: > > Alexey Borzenkov wrote: > > No, the bug is not that it gets wrong number of arguments. In fact, > > Windows has no concept of arguments, only C runtime does, which parses > > the command line. If command line is truncated, then C runtime will > > have missing

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Edward Lam wrote: >>> Ok, so where's the bug tracker so I can log a bug? >> Isn't this mailing list serving as bug tracker? I just hope that >> whoever can fix this is reading our emails and will come up with the >> right solution. > > Given the lack of developer acknowledgment (or refutation), I'

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Sat, May 30, 2009 at 04:23:22PM -0400, Edward Lam wrote: >>> Ok, so where's the bug tracker so I can log a bug? >> >> Isn't this mailing list serving as bug tracker? I just hope that >> whoever can fix this is reading our emails and will come up with the >> right solution. > >Given the lack of d

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

>> Ok, so where's the bug tracker so I can log a bug? > > Isn't this mailing list serving as bug tracker? I just hope that > whoever can fix this is reading our emails and will come up with the > right solution. Given the lack of developer acknowledgment (or refutation), I'm not getting my hopes u

[Fwd: Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line]

Repost for mailing list. On Sat, May 30, 2009 at 6:03 PM, Edward Lam wrote: >> Here, when I use russian Windows and I don't have LANG set (or when I >> have LANG=en_US.UTF-8), filename will be utf-8 multibyte string. So >> both, russian and european/chinese/japanese filenames will be valid. >> No

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

I'm reposting since I didn't mean to send this privately. On Fri, May 29, 2009 17:22, Alexey Borzenkov wrote: > Here, when I use russian Windows and I don't have LANG set (or when I > have LANG=en_US.UTF-8), filename will be utf-8 multibyte string. So > both, russian and european/chinese/japanese

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Sat, May 30, 2009 at 1:21 AM, Edward Lam wrote: > Here's some more investigation: [...] > So note that even when I'm seems to be an UNICODE-AWARE child process, I'm > still getting a truncated command line. In fact, call GetCommandLineW() > directly seems to give a truncated command line > as w

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Sat, May 30, 2009 at 1:04 AM, Edward Lam wrote: > Alexey Borzenkov wrote: >> It might be safe for you, but not for other people. If you have a >> Russian default codepage and ever need to work with chineese/japanese >> filenames and cygwin uses default codepage for filesystem operations >> (as

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Alexey Borzenkov wrote: > No, the bug is not that it gets wrong number of arguments. In fact, > Windows has no concept of arguments, only C runtime does, which parses > the command line. If command line is truncated, then C runtime will > have missing arguments when it tries to parse it. Sorry,

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Alexey Borzenkov wrote: > It might be safe for you, but not for other people. If you have a > Russian default codepage and ever need to work with chineese/japanese > filenames and cygwin uses default codepage for filesystem operations > (as in 1.5 right now), then you are really screwed. In my opi

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Sat, May 30, 2009 at 12:10 AM, Edward Lam wrote: > Thanks for explaining the UTF8 changes in cygwin 1.7. However, the decision > to use UTF-8 for the C locale is questionable. Not at all, because utf-8, as far as I understand, is used for communication with the system in this context, and does

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Hi Alexey, Thanks for explaining the UTF8 changes in cygwin 1.7. However, the decision to use UTF-8 for the C locale is questionable. It seems to me that it would be much safer to use the SYSTEM DEFAULT code page (ie. the return value of the system GetACP() function) for CYGWIN instead, ensu

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Fri, May 29, 2009 at 8:22 PM, Edward Lam wrote: > I think there is still a bug here? I set LANG=C, then shouldn't be just NOT > doing any encoding, thus work? If I do this on Linux, it works. If I use a > cygwin compiled app, it also works. On Linux, internally, system uses multibyte strings (

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

IWAMURO Motonori wrote: I think that you should set "export LANG=en_US.ISO-8859-1" instead of "export LANG=LANG=en_US.ISO-8859-1". Ah, sorry, copy/paste error. Yes, that finally works. Thank you! I think there is still a bug here? I set LANG=C, then shouldn't be just NOT doing any encoding, t

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

I think that you should set "export LANG=en_US.ISO-8859-1" instead of "export LANG=LANG=en_US.ISO-8859-1". 2009/5/30 Edward Lam : > IWAMURO Motonori wrote: >> >> The encoding of C locale is ASCII, and not ISO-8859-1. >> I don't think ASCII is the same as ISO-8859-1. >> Does it work on LANG=en_US.I

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

IWAMURO Motonori wrote: The encoding of C locale is ASCII, and not ISO-8859-1. I don't think ASCII is the same as ISO-8859-1. Does it work on LANG=en_US.ISO-8859-1? No, it doesn't. Mind you though, I haven't managed to get piconv to recognize any of my LANG settings other than C in cygwin 1.7.

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Hi. The encoding of C locale is ASCII, and not ISO-8859-1. I don't think ASCII is the same as ISO-8859-1. Does it work on LANG=en_US.ISO-8859-1? 2009/5/29 Edward Lam : > Alexey Borzenkov wrote: >> >> On Thu, May 28, 2009 at 7:28 PM, Edward Lam wrote: >>> >>> PS. In case you haven't noticed, copy

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Alexey Borzenkov wrote: On Thu, May 28, 2009 at 7:28 PM, Edward Lam wrote: PS. In case you haven't noticed, copyright.txt is not a long file. It consists of a single byte, 0xA9. Did you try utf-8 encoding copyright.txt? Perhaps your locale is utf-8 and the encoder fails. How is one supposed

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

On Thu, May 28, 2009 at 7:28 PM, Edward Lam wrote: > PS. In case you haven't noticed, copyright.txt is not a long file. It > consists of a single byte, 0xA9. Did you try utf-8 encoding copyright.txt? Perhaps your locale is utf-8 and the encoder fails. -- Unsubscribe info: http://cygwin.com/

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

PS. In case you haven't noticed, copyright.txt is not a long file. It consists of a single byte, 0xA9. Edward Lam wrote: Hi Larry, > This sounds allot like this report to me: > > I don't think it's the same bug because if I replace copyri

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Hi Larry, > This sounds allot like this report to me: > > I don't think it's the same bug because if I replace copyright.txt with a single printable character (eg. c), then it works. Regards, -Edward Larry Hall (Cygwin) wrote: Edward Lam w

Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line

Edward Lam wrote: Hi Cygwin 1.7 developers, I think I've encountered bug in cygwin 1.7.0-48 on WinXP 32-bit. It seems that passing a character on the command line (from either ash.exe or bash.exe) that is greater than 127 to a native win32 process results in arguments being truncated. Hopef

1.7.0-48: [BUG] Passing characters above 128 from bash command line

Hi Cygwin 1.7 developers, I think I've encountered bug in cygwin 1.7.0-48 on WinXP 32-bit. It seems that passing a character on the command line (from either ash.exe or bash.exe) that is greater than 127 to a native win32 process results in arguments being truncated. Hopefully you can reprod