Mail Archives: cygwin/2003/04/17/14:06:11
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/
- Raw text -