This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <edward@sidefx.com> 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 (it is encoding
agnostic even), but on Windows, system uses unicode strings, so cygwin
has to decode your byte sequences somehow to pass them to non-cygwin
processes as unicode (the fact that cygwin now understands unicode is
a huge plus to me). In earlier discussions it was decided that cygwin
C locale should use utf-8 encoding, because file system internally
uses unicode it's the safest default to represent all possible
filenames, etc. In previous cygwin versions, your byte sequences were
just silently converted using your system's codepage (by the system
itself, even), so if you want the old behavior you should set
LANG=en_US.CP1252.

The only bug here is that the arguments are truncated instead of using
some kind of a replacement character, is it related to some posix
complience, like with wprintf?

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]