Mail Archives: cygwin/2011/09/23/14:26:53
On Sep 23, 2011, at 10:41 AM, Andrew DeFaria wrote:
> On 9/23/2011 9:14 AM, Steve Atkins wrote:
>> On Sep 23, 2011, at 8:34 AM, Andrew DeFaria wrote:
>>
>>> On 09/23/11 07:55, Ryan Johnson wrote:
>>>> Wild speculation here...
>>>>
>>>> A quick test shows that ./a indeed works fine inside cygwin whether the '.exe' is present or not, though it would be a little challenging invoke such binaries directly from Windows.
>>>>
>>>> So... how hard would it be to provide "CYGWIN=(no)disabletransparent_exe"?*** There could a very simple utility, similar to rebaseall, which strips the .exe extension from cygwin executables (identifiable from cygcheck or their presence in standard paths), and which accepts additional paths to clean up. People needing the functionality would be responsible run the utility properly (after installing new packages, don't mess with Windows paths, etc.).
>>>>
>>>> That would require no changes to any package to give the desired behavior, and as packages change they would just fit right in (no .exe in the package ==> no fuss).
>>>>
>>>> Of course, SHTDI...
>>>>
>>>> Ryan
>>>>
>>>> *** The old, removed "transparent_exe" has the wrong boolean sense to work the correct way by default
>>>>
>>> What do you do about say, Foo.c and foo.c?
>> The same as you do now on cygwin and on other case-preserving but case-insensitive filesystems - treat them as identical. That's still a little annoying, but not uncommon on unix-ish environments (OS X as one common example) so people already are aware of it and work around it.
>>
>> Cheers,
>> Steve
> My point, obviously missed, was that I thought that the issue here was that if you untar a tar which contains say a.exe and a as two different files the later one will overwrite the former due to the way that Cygwin treats files that end in .exe. Wouldn't you have a similar problem if you had Foo.c and foo.c in the tar image? (Note I didn't know about that registry setting which is interesting and which I'd venture to guess nobody runs with).
>
> If people "work around" the Foo.c/foo.c issue, presumably by renaming one of the files, couldn't they likewise "work around" the a.exe/a issue?
I'm talking about developers of applications, not cygwin-using end users. The developers could work around it (by not including .exe bootstrap files in cross-platform packages or being careful with naming), but they don't because it's not an issue that would ever occur to them, unlike case-insensitivity.
Many systems are case-insensitive - and, more importantly, at least one system that's commonly used by developers is - so most software is developed and packaged with that in mind. Case insensitivity is a well understood issue. Only one system, cygwin, considers foo and foo.exe to be identical. It's a niche environment, and not used by many developers who target a unix-style environment, so most developers packaging software will not be aware of the issue and won't work around it.
Treating "foo" and "foo.exe" as equivalent is a very non-unixy thing to do ("everything is a file, and the name of the file isn't important to the kernel") so it's particularly surprising behaviour on a system that otherwise looks quite like a unix environment.
(I'd assumed that cygwin worked by intercepting execve(), and it hadn't even occurred to me that it would modify filesystem access at a coarser level than that until I started diagnosing apparent bugs in tar).
It's not a serious problem, of course - but it does mean that the most widely used cross-platform GUI library cannot be unpacked on cygwin and built from source without jumping through hoops. Given that the cygwin environment is very attractive to cross-platform developers I'm betting I'm not the first person who has been burned by this, and won't be the last.
I'm not sure what the best thing to do about it is - but even a user level patch to tar and unzip to warn when it's done something unexpected would have saved me quite a lot of grief.
Cheers,
Steve
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -