Problem in executable file mechanism

[Andrew DeFaria]

Corinna Vinschen wrote:

> On Wed, Apr 16, 2003 at 12:58:20PM -0400, Igor Pechtchanski wrote:
>
>> On Wed, 16 Apr 2003, Corinna Vinschen wrote:
>>
>>> On Wed, Apr 16, 2003 at 11:56:32AM -0400, Igor Pechtchanski wrote:
>>>
>>>> Try "strace sh -c ls".
>>>> Igor
>>>
>>> Well... let's get serious. What do you expect? Think UNIX. The 
>>> executable is 'ls'. The directory is 'ls'. This is only possible on 
>>> Windows because the executables have this .exe suffix. On UNIX this 
>>> won't be a problem since there wouldn't be two files with the same 
>>> name in a directory.
>>>
>>> Corinna
>>
>> Yes. But since such a mechanism *was* introduced in Cygwin, shouldn't 
>> the executable take precedence, at least for an exec() call? I can't 
>> think of a situation when anyone would want to exec() a directory...
>
> That's not the point. The point is that calls like stat() will find 
> "/usr/bin/ls" before finding "/usr/bin/ls.exe". That's correct in 99% 
> of the cases. Just in the coincidental case of having a dir and
> a binary of the same name in the same directory, returning "ls" before 
> "ls.exe" is incorrect. But, honestly, how should stat() know that its 
> behaviour should suddenly be different than in the other 99% cases?
>
> The answer to the original posters problem is that simple: Don't do this.

Couldn't exec (shouldn't exec) stat /usr/bin/ls as expected but then see 
that that is a directory and then continue on in the algorithm to stat 
/usr/bin/ls.exe? Again, just because you found a candidate (/usr/bin/ls) 
does not mean that you should necessarily attempt to run it (i.e. run a 
directory!).



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