This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Directory existence prevents .exe execution

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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]