Re: cygwin semantics of ..

[Jim Meyering]

address@hidden (Eric Blake) wrote:
>> Daunting, but above all, invasive and probably counterproductive,
>> assuming such a bug won't remain for long.  With Cygwin, such fundamental
>> bugs make it seem that is will be relatively easy to tell users they need
>> to upgrade to a newer version.
>
> The problem is that the cygwin maintainers are arguing that
> the bug WILL remain for a long time - they claim that fixing it
> in cygwin is too invasive and too much of a speed penalty to
> the bottleneck path conversion code already in place.  I disagree
> with their attitude (standards exist for a reason, after all, even in
> the corner cases), but have not yet been able to sway them to fix
> the bug - it has been an ongoing battle for more than a year.

Well, this *is* a bit of a corner case.
I can sympathize with their not wanting to fix it,
if the cost would really be that high.

Even if the non-conforming behavior is here to stay, I don't want
to see sweeping changes (or create/maintain many wrappers) that
make coreutils work around such Cygwin-specific bugs.

I'm happy to leave coreutils the way it is, but if you want to
avoid a test failure or two on Cygwin, I'd welcome a patch that
would make `make check' skip the offending tests.