Directory existence prevents .exe execution

[Larry Hall (Cygwin)]

Luke Kendall wrote:
> Larry Hall (Cygwin) wrote:
>> Luke Kendall wrote:
>>> 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 think you did as well.  And so does bash.  But it's not going to allow
>> you to execute a directory, which is what your invocation matches 
>> exactly.
>> So it tells you that you made a mistake by trying to execute a directory.
>> I guess we're in violent agreement that you got what you asked for.
>>
> Well, not violent, but clear disagreement. :-)
> I think that given I can type "foo" to execute foo or foo.exe, why does 
> having a directory called foo make bash decide that I want to do the 
> impossible: namely, execute the directory?  Why is it written to assume 
> that the user is trying to do something that makes no sense?

"foo" only matches "foo.exe" if there is no actual "foo" entry in the
directory being searched.   It's assumed that there's no need for heuristics
if an exact match is found.

> I suspect it won't become clear until I have time to grab the bash 
> source and probably the exec source and read them through myself.

Probably true.

>>> 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.
>>
>> Well here you're not comparing the same thing at all.  You can't put a
>> file/binary named "ici" in the same spot as a directory you have named
>> "ici".  So you've already changed the rules.  But try the exact same
>> thing you just did under Linux on Cygwin and you'll see the same
>> behavior as Linux.
> 
> I had to move the Ici directory aside, but I confirmed that you're 
> correct.  So it looks like you understand what's going on better than I 
> do, since I don't understand why and you do. :-)

Actually, you got it below.

>>   The point is that Windows allows you to do something
>> you can't do in Linux.  You can have the name of an executable match the
>> name of a directory, if you ignore the extension.  In addition you can
>> run an executable by only providing part of its name (i.e. not the
>> extension).  You can't do this under Linux.  And why would you want to.
> Quite!
>> But if you try to put that same-named executable and directory under the
>> one directory and then run the executable from there without providing
>> the full name, you're being imprecise.  Cygwin's bash lets you know this.
>> You can't compare this behavior to Linux because you'd never get into
>> that situation.
>>
> True, but given that Cygwin is designed to allow the user to be 
> imprecise (drop the .exe suffix) when asking for a command to be 
> executed, why have that logic (designed to improve usability because of 
> the "interesting" decision to identify executables by suffix) decide 
> that if the name matches a directory, then the user is really trying to 
> execute a directory.  One thing we agree on, is that it makes no sense 
> to try to execute a directory.

Which is why bash won't let you.

>> Don't confuse any of this with an executable named "ici.exe" in one
>> directory in your path and a directory named "ici" in another (also
>> in your path).  This isn't a general issue that will bite you every
>> time you want to run "ici.exe" in this configuration.  In this scenario,
>> the only time running "ici.exe" as "ici" would cause you to get the
>> complaint that "ici" is a directory is if you were trying to run it from
>> the parent directory of "ici"-the-directory.
> Well, I'm getting the problem regardless of what directory I try to run 
> the command from.  I don't get the problem only if I'm trying to run ici 
> when my current directory is /opt/bin.
> 
> Unless you mean that the problem only occurs when I specify the full 
> pathname, and that pathname is a directory of that name and there is a 
> .exe file there based on the same name, too.

That's one way.  The other would be if you're in the directory with
both "ici.exe" and "ici"-the-directory.

> Which would make sense because in that case the search down PATH is not 
> done, where it looks for a command with the right name (maybe with .exe 
> or .lnk extension) to run...
> 
> Which makes me think that exec() (or execve or whatever is the exec() 
> that searches down the PATH) is the place where the check for .exe with 
> rejection of directories, makes sense.  That change would fix the 
> problem in all shells, too, not just bash.

As Corinna mentioned in her reply, this is a slippery slope.  It's hard
to argue that we need to introduce more complex logic to a bunch of
system calls just to handle this corner case.

> And I'm sorry if you are now tearing your hair out wondering why I don't 
> get it,still.  :-(
>>   And if you take that parent
>> directory (and "." if you have that) out of your path, you can run 
>> "ici.exe"
>> as "ici" from anywhere.
>>
>> Better?
>>
> I'm afraid I may still be misunderstanding, sorry.  Do you mean, move 
> the ici directory to some place away from where the ici.exe lives?

Exactly.  You can put it anywhere you want, even in your path, but it
can't be in the same directory as the executable if you're going to
continue to name it the same as the executable.  IOW, same as *nix.


-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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