This is the mail archive of the cygwin@sources.redhat.com 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]

RE: non latin file names?



>
> >Problem 1 - SAMBA and 8-bit characters.
> >
> >You must tell SAMBA what OEM code page is used by your client. This is
> >probably either 850 or 437. You better ask on SAMBA list about
> this problem.
>
> most likely this is the problem, I've done some more hacking (trying
> to answer your previous questions with a step by step demo you
> could run yourself to do a bare minimum recreation) and I see that
> whatever error is happening on the xfr from windows to linux via
> samba it's orthogonal... gigo... such that even though the filename
> becomes garbage on linux, it's at least consistently able to spit
> it back to me correctly on NT. I'll follow up with a samba guru I
> know at work. The root problem in this case was that, while the two
> files appeared to have the same file name, with the same glyphs,
> at a binary level they didn't match... cygwin on nt wanted to use
> 0xF3, but the file that came over from linux had 0xA2.
>

Cygwin is obviously using ANSI code page, while file comes to Linux in OEM
code page (additionally, SAMBA may, if configured, convert OEM code page to
whatever local character set is used on server). Unless all parties agree to
use single charset - and that should be some version of Unicode for general
case - problem remains.

Our good fellas in ASCII world are _very_ lucky to not have this problem.

> >Problem 2 - locale support in Cygwin
> >
> >Cygwin does not have any locale support at all. There is stub
> implementation
> >for setlocale that basically sets locale to C. Two possible implementations
> >are:
> >
> >- use own locale database (basically, reimplement standard glibc locale
> >support)
> >- rely on Windows locale support if possible.
> >
> >I prefer the second.
>
> I'd vote for the first, namely a port of gconv... the GNU impl of
> iconv... clean and posix compliant as opposed to whatever m$ came
> up with... not that I'm too familiar with m$'s "solution", just
> making a prediction based on past experience. (iconv otoh I am
> familiar with... it rocks.)
>

I beg your pardon, but iconv has very little to do with it. iconv is just a
standalone program, that translates between different charsets. Most probably,
it will compile OOTB. It's not going to help you with ls problem. What I was
talking about, was different implementations of locale support in cygwin
"kernel" or run-time. So, that _every_ program that is written with locale
support in mind (i.e. is using ctype functions at the very least), would work
correctly.

In this respect, using Windows locale seems to be the correct way.

cheers

-andrej


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


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