Directory existence prevents .exe execution

[Luke Kendall]

Larry Hall (Cygwin) wrote:
> On 04/18/2008, Luke Kendall wrote:
>> Larry Hall (Cygwin) wrote: What do you mean by Cygwin, in this case?
>> Bash?  Cygwin's implementation of exec()?
>
> In this case, bash.  Try it from, say, csh, and you'll see something a
> bit different.
>
$ /opt/bin/ici -help

CORRECT>/opt/bin/Ici -help (y|n|e|a)? no
/opt/bin/ici: Command not found.
$ /opt/bin/ici -help

CORRECT>/opt/bin/Ici -help (y|n|e|a)? yes
/opt/bin/Ici: Permission denied.

Yep, it's no better.  It even specifically offers me the optio to try to 
execute the directory.
>>> It uses stat() to find out what type of thing "foo" is.  Then it uses
>>> that information to decide how to handle "foo".
>>>
>> This is why I'm saying that something that handles the invocation of 
>> programs under Cygwin tries to execute directories:
>>
>> $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory $ whiches ici 
>> /opt/bin/ici.exe /opt/bin/ici.dll /cygdrive/x/bin/ici.exe 
>> /cygdrive/x/bin/ici.dll $ ls -ld /opt/bin/Ici drwxr-xr-x 1 luke Domain
>> Users 0 Oct 17  2005 /opt/bin/Ici
>>
>> It looks like something has stat()ed /opt/bin/ici and then decided 
>> it's been asked to execute that, and refusing (which makes a kind of 
>> sense),
>> and bailing out with an error (*that* step seems wrong to me).
>
> Well, didn't you ask to execute '/opt/bin/ici'?  After all, that's 
> what you
> typed.  I don't see how it could be wrong to report back what you 
> asked to
> execute is a directory.
>
I thought that bash treated the first word on the line (after optional 
assignments to environment variables a la FRED=x run-some-command) as a 
command to execute, passing the remaining words on the line to the 
command as arguments?  (Leaving aside things like backtic execution and 
variable expansion.)

So I still think I asked for /opt/bin/ici to be executed by bash.  I'd 
be interested to know if I've misunderstood.

I also checked that bash doesn't work this way under Linux.  I created a 
directory called ici (with execute permission, obviously), in the first 
directory in my PATH.  I then ran ici from bash, and it did not tell me 
that ici was a directory and bail out - it executed the first ici 
executable it found later in my PATH.

That's all I was hoping that Cygwin's bash would do, too.  zsh under 
Cywgin is worse, though:
$ /opt/bin/ici -help
zsh: no such file or directory: /opt/bin/ici


>> I assumed that the logic which invokes foo.exe when you type foo 
>> should not be trying to execute a directory called foo.  It's never 
>> right to try to execute a directory.
>
> True enough.  Hence the message.  The directory isn't being executed 
> here.
>
>> I'm suggesting that instead of trying to do that and reporting an 
>> error and failing, the code should just skip past that as obviously 
>> wrong and fall through to the rest of its logic, which would in fact 
>> do the right thing - even if the foo.exe was in some other directory 
>> entirely, later on the PATH!
>
> If you ask for 'foo' or '/path/to/foo' and that's a directory, going 
> beyond
> that looking for something else when you've found an exact match is a bit
> dangerous.  You don't want to be taking too many liberties with the exe
> magic.  Things could get ugly fast.  That said, if you want an executable
> to be named "foo" and not "foo.exe", you can do that on NT-based 
> platforms.
> But again, here you're back to a situation where you won't be able to 
> have
> a same-named directory right beside the executable.  But that matches 
> *nix.
>
>


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