Mail Archives: cygwin/2008/04/18/01:02:53
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/
- Raw text -