This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Dec 7 18:50, Bengt Larsson wrote:
> Corinna Vinschen wrote:
> >On Dec 7 18:00, Bengt Larsson wrote:
> >> Corinna Vinschen wrote:
> >> >- cygwin_conv_path and cygwin_conv_path_list: In CCP_WIN_A_TO_POSIX and
> >> > CCP_POSIX_TO_WIN_A conversions, use the current Windows ANSI or OEM
> >> > charset, depending on the return value of AreFileApisANSI. Up to Cygwin
> >> > 1.7.9, both conversions used the current Cygwin charset for the conversion.
> >> Is that the right thing to do? I have LANG=C.UTF-8. If I pass a
> >> Windows-style filename on the command line, it's passed as UTF-8. How do
> >> I then convert that to Unix-style, UTF-8?
> >First of all, don't do that. Use POSIX paths.
> >Second, it's not passed as UTF-8 if the called application is a
> >non-Cygwin application. In fact, Cygwin calls CreateProcessW, so all
> >strings are converted to UTF-16 (aka UNICODE) when starting a non-Cygwin
> >child process.
> >Third, as for Cygwin apps, don't use WIN_A, use WIN_W instead, because
> >that's encoding agnostic:
> OK, thanks.
Just so it's clear why I did that, maybe you want to have a look into
the brief discussion on the cygwin-developers list:
Basically, apart from external sources, the multibyte Windows paths you
have are either returned from a Windows function, or they are supposed
to be put into a Windows function. Since the multibyte Windows file
access functions use the ANSI or OEM codepage, it makes sense to use the
current ANSI or OEM codepage for the WIN_A conversions as well. But in
fact I agree with Daniel's comment on the list:
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple