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/
