Directory existence prevents .exe execution

Directory existence prevents .exe execution

[Luke Kendall]

We have the Ici scripting language installed on Windows.  Ici expects a 
directory called "ici" to exist alongside, where various libraries are 
installedd to provide extra functionality.

Unfortunately, under Cygwin, if w try to run the command "ici" we get 
the error "ici: command not found", because Cygwin chooses to try to 
execute the directory instead of the .exe:

$ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr
bash: /opt/bin/ici: is a directory
$ ls -ld /opt/bin/ici
drwxr-xr-x 1 luke Domain Users 0 Oct 17  2005 /opt/bin/ici
$ ls -ld /opt/bin/ici.*
-rwxr-xr-x 1 luke Domain Users 233503 Apr 18  2000 /opt/bin/ici.dll
-rwxr-xr-x 1 luke Domain Users  24576 Jan 29  2003 /opt/bin/ici.exe

I tried naming the ici directory Ici but it made no difference.
The directory /opt/bin is mounted like so:
$ mount
\\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system 
(textmode,exec)

Using binmode doesn't help.  Is this a bug, that bash tries to execute a 
directory even when there's an executable (with an implicit .exe suffix, 
naturally) of the same name in existence ?  If not, can anyone suggest a 
workaround?  I can't just append a .exe to the #!/opt/bin/ici shell 
wrapper since then the scripts wouldn't run from Unix.

Is there a bash option that controls this, maybe (I couldn't see one)?

Regards,

luke

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

Re: Directory existence prevents .exe execution

[Igor Peshansky]

On Wed, 16 Apr 2008, Luke Kendall wrote:

> We have the Ici scripting language installed on Windows.  Ici expects a
> directory called "ici" to exist alongside, where various libraries are
> installedd to provide extra functionality.
>
> Unfortunately, under Cygwin, if w try to run the command "ici" we get
> the error "ici: command not found", because Cygwin chooses to try to
> execute the directory instead of the .exe:

This behavior (preferring the unadorned file name to the .exe) has been in
existence for a while (at least a year).  We relied on the old behavior by
having a script and a .exe with the same name (and expecting the .exe to
be invoked on Windows/Cygwin).  I remember we've had to work around this
issue when the change happened, by prepending the following to our script:

[ -x "$0.exe" ] && exec "$0.exe" "$@"

> $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr
> bash: /opt/bin/ici: is a directory
> $ ls -ld /opt/bin/ici
> drwxr-xr-x 1 luke Domain Users 0 Oct 17  2005 /opt/bin/ici
> $ ls -ld /opt/bin/ici.*
> -rwxr-xr-x 1 luke Domain Users 233503 Apr 18  2000 /opt/bin/ici.dll
> -rwxr-xr-x 1 luke Domain Users  24576 Jan 29  2003 /opt/bin/ici.exe
>
> I tried naming the ici directory Ici but it made no difference.

Try also CYGWIN="$CYGWIN check_case:strict" (while the code is still in
the DLL) or managed mounts...  The latter won't work unless ici.exe is a
Cygwin program.

> The directory /opt/bin is mounted like so:
> $ mount
> \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system (textmode,exec)
>
> Using binmode doesn't help.  Is this a bug, that bash tries to execute a
> directory even when there's an executable (with an implicit .exe suffix,
> naturally) of the same name in existence ?

No, this is expected behavior (if you search through bash release
announcements, you should be able to see the exact point at which the
change happened).

> If not, can anyone suggest a workaround?

Other than renaming the directory or using a wrapper script, no.

> I can't just append a .exe to the #!/opt/bin/ici shell wrapper since
> then the scripts wouldn't run from Unix.

How do these scripts *ever* run from Unix?  Unix would definitely not be
aware of the .exe suffix, and would always attempt to execute
/opt/bin/ici, which, as you say, is a directory.  Do you have a
/opt/bin/ici script as well?

In any case, whatever solution you use to make it work from Unix should
work on Cygwin as well.

> Is there a bash option that controls this, maybe (I couldn't see one)?

There is no bash option to control this, AFAIK.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"That which is hateful to you, do not do to your neighbor.  That is the whole
Torah; the rest is commentary.  Go and study it." -- Rabbi Hillel

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

Re: Directory existence prevents .exe execution

[Luke Kendall]

Igor Peshansky wrote:
> On Wed, 16 Apr 2008, Luke Kendall wrote:
>
>   
>> We have the Ici scripting language installed on Windows.  Ici expects a
>> directory called "ici" to exist alongside, where various libraries are
>> installedd to provide extra functionality.
>>
>> Unfortunately, under Cygwin, if w try to run the command "ici" we get
>> the error "ici: command not found", because Cygwin chooses to try to
>> execute the directory instead of the .exe:
>>     
>
> This behavior (preferring the unadorned file name to the .exe) has been in
> existence for a while (at least a year).
Interesting.  Do you mean that exec() prefers the unadorned file name to 
the .exe?  Or do you mean bash or something else changed to prefer the 
unadorned name?  From what you say below, I think you mean bash changed.

>   We relied on the old behavior by
> having a script and a .exe with the same name (and expecting the .exe to
> be invoked on Windows/Cygwin).  I remember we've had to work around this
> issue when the change happened, by prepending the following to our script:
>
> [ -x "$0.exe" ] && exec "$0.exe" "$@"
>
>   
Our olden approach, maybe 5-10 years ago, we wrote a script that 
examined the 1st line of some target script to generate a C program 
(that was compiled to a .exe of the same name) that invoked the named 
interpreter on the target script.  This was needed for U/Win.  Then we 
changed over to Cygwin and discovered we didn't need to do this: Cygwin 
supported #! magic.  But some time ago it stopped working in this corner 
case and I finally got around to asking about it.

To follow the approach you took for your case, we could convert all our 
ici scripts to shell scripts and um, what, set ICI to either 
/opt/bin/ici or /opt/bin/ici.exe depending on whether we detect the 
script is on Windows and then:

exec $ICI -f - "$@" <<'some-eof-mark'

But that wouldn't work, would it, since we'd still have to backslash 
escape any backtic character in the script?  Shudder.
>> $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr
>> bash: /opt/bin/ici: is a directory
>> $ ls -ld /opt/bin/ici
>> drwxr-xr-x 1 luke Domain Users 0 Oct 17  2005 /opt/bin/ici
>> $ ls -ld /opt/bin/ici.*
>> -rwxr-xr-x 1 luke Domain Users 233503 Apr 18  2000 /opt/bin/ici.dll
>> -rwxr-xr-x 1 luke Domain Users  24576 Jan 29  2003 /opt/bin/ici.exe
>>
>> I tried naming the ici directory Ici but it made no difference.
>>     
>
> Try also CYGWIN="$CYGWIN check_case:strict" (while the code is still in
> the DLL) or managed mounts...  The latter won't work unless ici.exe is a
> Cygwin program.
>
>   
Thanks for the suggestion, but it didn't help:

$ echo $CYGWIN
nobinmode
$ CYGWIN="$CYGWIN check_case:strict"
$ ici -help
bash: ici: command not found
$ /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
$ type ici
bash: type: ici: not found
$ which ici
ici: Command not found.
$ CYGWIN=nobinmode
$ ici -help
bash: ici: command not found
$ /opt/bin/ici -help
bash: /opt/bin/ici: is a directory

>> The directory /opt/bin is mounted like so:
>> $ mount
>> \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system (textmode,exec)
>>
>> Using binmode doesn't help.  Is this a bug, that bash tries to execute a
>> directory even when there's an executable (with an implicit .exe suffix,
>> naturally) of the same name in existence ?
>>     
>
> No, this is expected behavior (if you search through bash release
> announcements, you should be able to see the exact point at which the
> change happened).
>   
I had a look, but couldn't find the release notes.  Do you mean, the 
release notes for each of the bash updates announced on the mailing 
list?  Or do you mean the full release notes - if so, any idea where I'd 
find them?

I looked at the release notes for all the mailing list announcements for 
bash over the last few years, and searched for "unadorned" and "exec".  
Sorry for asking.
>> If not, can anyone suggest a workaround?
>>     
>
> Other than renaming the directory or using a wrapper script, no.
>
>   
>> I can't just append a .exe to the #!/opt/bin/ici shell wrapper since
>> then the scripts wouldn't run from Unix.
>>     
>
> How do these scripts *ever* run from Unix?  Unix would definitely not be
> aware of the .exe suffix, and would always attempt to execute
> /opt/bin/ici, which, as you say, is a directory.  Do you have a
> /opt/bin/ici script as well?
>
>   
No, ici on Unix looks elsewhere for its libraries, since it can't use 
such a simple system as having the directory alongside the .exe with the 
same name but the suffix stripped, for obvious reasons.
> In any case, whatever solution you use to make it work from Unix should
> work on Cygwin as well.
>
>   
True.  We can modify the ici source to also have a directory search path 
for the libraries, and move the ici directory somewhere else that's off 
the PATH search path, and that will solve this problem.

I guess that's what we'll do.

But we'll then have the problem that Windows native compiled ici won't 
be able to open any named scripts that aren't given with Windows 
pathnames, not Cygwin ones.  Fair enough, it's just like any other 
native Windows application in that respect.

And we could compile up a version under Cygwin for use in Cygwin.
>> Is there a bash option that controls this, maybe (I couldn't see one)?
>>     
>
> There is no bash option to control this, AFAIK.
> 	Igor
>   
Okay, thanks Igor.

luke

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

RE: Directory existence prevents .exe execution

[Luke Kendall]

On 15 Apr, Dyck, David wrote:
>  how much control do you have on unix side?
>   (you could create a symlink from ici.exe to ici on unix.

True.  And I suppose there are only rare programs that would suffer
this problem.

>  what about creating a new name for ici.exe and ici that
>  could be found on both.

Umm, I don't think I understand.  Then we'd have to modify every script
to change the #!/opt/bin/ici, wouldn't we?

>  directories need to have 'x' attribute to be searchable (on unix)
>  but I would also ask about your path
>  
>  why do you need an /opt/bin/ici directory on windows
>  when if /opt/bin/ici was a directory on unix, where
>  would the shell be finding "ici" executable? 

On Unix, it would be finding it under /opt/ici-3.0.1/lib/ici3.
Since it should also work under Windows natively, we can't rely on
using mount points under Cygwin, since they just wouldn't be visible.

But maybe we could do something along those lines.

It does seem like a corner case (in bash or in the exec call), that
Cygwin would be better for handling.  This corner case can't happen in
Unix because Unix doesn't have implicit suffixes on commands: you can't
have a directory and an executable in the same directory with the same
name.  (If you have a command called fred.sh, you type fred.sh to
execute it, not fred.)

I assume exec() stat()s a file, and then presumably does some special
magic to change "fred" to "fred.exe" if it can't find "fred".

Suppose that when it does a stat() on "fred", before it decides that
it's found the right file to exec, it should check that "fred" isn't a
directory.  If it is a directory, it should consider that "not found"
and the logic would flow through into the checking for ".exe" and
whatever other arcane Windows executable-file suffixes make sense.

But having not looked at the source, I confess I'm just guessing.

Thanks,

luke

> > -----Original Message-----
> > From: cygwin-owner@cygwin.com 
> > [mailto:cygwin-owner@cygwin.com] On Behalf Of Luke Kendall
> > Sent: Tuesday, April 15, 2008 9:44 PM
> > To: cygwin@cygwin.com
> > Subject: Directory existence prevents .exe execution
> > 
> > We have the Ici scripting language installed on Windows.  Ici 
> > expects a 
> > directory called "ici" to exist alongside, where various 
> > libraries are 
> > installedd to provide extra functionality.
> > 
> > Unfortunately, under Cygwin, if w try to run the command "ici" we get 
> > the error "ici: command not found", because Cygwin chooses to try to 
> > execute the directory instead of the .exe:
> > 
> > $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr
> > bash: /opt/bin/ici: is a directory
> > $ ls -ld /opt/bin/ici
> > drwxr-xr-x 1 luke Domain Users 0 Oct 17  2005 /opt/bin/ici
> > $ ls -ld /opt/bin/ici.*
> > -rwxr-xr-x 1 luke Domain Users 233503 Apr 18  2000 /opt/bin/ici.dll
> > -rwxr-xr-x 1 luke Domain Users  24576 Jan 29  2003 /opt/bin/ici.exe
> > 
> > I tried naming the ici directory Ici but it made no difference.
> > The directory /opt/bin is mounted like so:
> > $ mount
> > \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system 
> > (textmode,exec)
> > 
> > Using binmode doesn't help.  Is this a bug, that bash tries 
> > to execute a 
> > directory even when there's an executable (with an implicit 
> > .exe suffix, 
> > naturally) of the same name in existence ?  If not, can 
> > anyone suggest a 
> > workaround?  I can't just append a .exe to the #!/opt/bin/ici shell 
> > wrapper since then the scripts wouldn't run from Unix.
> > 
> > Is there a bash option that controls this, maybe (I couldn't see one)?
> > 
> > Regards,
> > 
> > luke
> > 
> > --
> > 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/
> > 
> > 
> > 
>  
>  This message (including any attachments) contains confidential 
>  and/or proprietary information intended only for the addressee.  
>  Any unauthorized disclosure, copying, distribution or reliance on 
>  the contents of this information is strictly prohibited and may 
>  constitute a violation of law.  If you are not the intended 
>  recipient, please notify the sender immediately by responding to 
>  this e-mail, and delete the message from your system.  If you 
>  have any questions about this e-mail please notify the sender 
>  immediately. 
>  



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

Re: Directory existence prevents .exe execution

[Mark J. Reed]

I still don't understand why you would put the ici dir in the same
place as the ici script.  You can't do that on Unix, so why do it on
Cygwin?



On 4/16/08, Luke Kendall <luke.kendall@cisra.canon.com.au> wrote:
> On 15 Apr, Dyck, David wrote:
> >  how much control do you have on unix side?
> >   (you could create a symlink from ici.exe to ici on unix.
>
> True.  And I suppose there are only rare programs that would suffer
> this problem.
>
> >  what about creating a new name for ici.exe and ici that
> >  could be found on both.
>
> Umm, I don't think I understand.  Then we'd have to modify every script
> to change the #!/opt/bin/ici, wouldn't we?
>
> >  directories need to have 'x' attribute to be searchable (on unix)
> >  but I would also ask about your path
> >
> >  why do you need an /opt/bin/ici directory on windows
> >  when if /opt/bin/ici was a directory on unix, where
> >  would the shell be finding "ici" executable?
>
> On Unix, it would be finding it under /opt/ici-3.0.1/lib/ici3.
> Since it should also work under Windows natively, we can't rely on
> using mount points under Cygwin, since they just wouldn't be visible.
>
> But maybe we could do something along those lines.
>
> It does seem like a corner case (in bash or in the exec call), that
> Cygwin would be better for handling.  This corner case can't happen in
> Unix because Unix doesn't have implicit suffixes on commands: you can't
> have a directory and an executable in the same directory with the same
> name.  (If you have a command called fred.sh, you type fred.sh to
> execute it, not fred.)
>
> I assume exec() stat()s a file, and then presumably does some special
> magic to change "fred" to "fred.exe" if it can't find "fred".
>
> Suppose that when it does a stat() on "fred", before it decides that
> it's found the right file to exec, it should check that "fred" isn't a
> directory.  If it is a directory, it should consider that "not found"
> and the logic would flow through into the checking for ".exe" and
> whatever other arcane Windows executable-file suffixes make sense.
>
> But having not looked at the source, I confess I'm just guessing.
>
> Thanks,
>
> luke
>
> > > -----Original Message-----
> > > From: cygwin-owner@cygwin.com
> > > [mailto:cygwin-owner@cygwin.com] On Behalf Of Luke Kendall
> > > Sent: Tuesday, April 15, 2008 9:44 PM
> > > To: cygwin@cygwin.com
> > > Subject: Directory existence prevents .exe execution
> > >
> > > We have the Ici scripting language installed on Windows.  Ici
> > > expects a
> > > directory called "ici" to exist alongside, where various
> > > libraries are
> > > installedd to provide extra functionality.
> > >
> > > Unfortunately, under Cygwin, if w try to run the command "ici" we get
> > > the error "ici: command not found", because Cygwin chooses to try to
> > > execute the directory instead of the .exe:
> > >
> > > $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr
> > > bash: /opt/bin/ici: is a directory
> > > $ ls -ld /opt/bin/ici
> > > drwxr-xr-x 1 luke Domain Users 0 Oct 17  2005 /opt/bin/ici
> > > $ ls -ld /opt/bin/ici.*
> > > -rwxr-xr-x 1 luke Domain Users 233503 Apr 18  2000 /opt/bin/ici.dll
> > > -rwxr-xr-x 1 luke Domain Users  24576 Jan 29  2003 /opt/bin/ici.exe
> > >
> > > I tried naming the ici directory Ici but it made no difference.
> > > The directory /opt/bin is mounted like so:
> > > $ mount
> > > \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system
> > > (textmode,exec)
> > >
> > > Using binmode doesn't help.  Is this a bug, that bash tries
> > > to execute a
> > > directory even when there's an executable (with an implicit
> > > .exe suffix,
> > > naturally) of the same name in existence ?  If not, can
> > > anyone suggest a
> > > workaround?  I can't just append a .exe to the #!/opt/bin/ici shell
> > > wrapper since then the scripts wouldn't run from Unix.
> > >
> > > Is there a bash option that controls this, maybe (I couldn't see one)?
> > >
> > > Regards,
> > >
> > > luke
> > >
> > > --
> > > 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/
> > >
> > >
> > >
> >
> >  This message (including any attachments) contains confidential
> >  and/or proprietary information intended only for the addressee.
> >  Any unauthorized disclosure, copying, distribution or reliance on
> >  the contents of this information is strictly prohibited and may
> >  constitute a violation of law.  If you are not the intended
> >  recipient, please notify the sender immediately by responding to
> >  this e-mail, and delete the message from your system.  If you
> >  have any questions about this e-mail please notify the sender
> >  immediately.
> >
>
>
>
> --
> 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/
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Mark J. Reed <markjreed@gmail.com>

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

Re: Directory existence prevents .exe execution

[Luke Kendall]

Mark J. Reed wrote:
> I still don't understand why you would put the ici dir in the same
> place as the ici script.  You can't do that on Unix, so why do it on
> Cygwin?
>
>   
The creator did this because simply it seemed a convenient way to keep 
all the ici components together and easy to install and uninstall, and 
it also caused no problems for the Windows cmd.exe shell.  cmd doesn't 
try to execute directories as if they were programs.  ici has been 
around for about 25 years, so it wasn't designed with Cygwin in mind.

luke
>
> On 4/16/08, Luke Kendall <luke.kendall@cisra.canon.com.au> wrote:
>   
>> On 15 Apr, Dyck, David wrote:
>>     
>>>  how much control do you have on unix side?
>>>   (you could create a symlink from ici.exe to ici on unix.
>>>       
>> True.  And I suppose there are only rare programs that would suffer
>> this problem.
>>
>>     
>>>  what about creating a new name for ici.exe and ici that
>>>  could be found on both.
>>>       
>> Umm, I don't think I understand.  Then we'd have to modify every script
>> to change the #!/opt/bin/ici, wouldn't we?
>>
>>     
>>>  directories need to have 'x' attribute to be searchable (on unix)
>>>  but I would also ask about your path
>>>
>>>  why do you need an /opt/bin/ici directory on windows
>>>  when if /opt/bin/ici was a directory on unix, where
>>>  would the shell be finding "ici" executable?
>>>       
>> On Unix, it would be finding it under /opt/ici-3.0.1/lib/ici3.
>> Since it should also work under Windows natively, we can't rely on
>> using mount points under Cygwin, since they just wouldn't be visible.
>>
>> But maybe we could do something along those lines.
>>
>> It does seem like a corner case (in bash or in the exec call), that
>> Cygwin would be better for handling.  This corner case can't happen in
>> Unix because Unix doesn't have implicit suffixes on commands: you can't
>> have a directory and an executable in the same directory with the same
>> name.  (If you have a command called fred.sh, you type fred.sh to
>> execute it, not fred.)
>>
>> I assume exec() stat()s a file, and then presumably does some special
>> magic to change "fred" to "fred.exe" if it can't find "fred".
>>
>> Suppose that when it does a stat() on "fred", before it decides that
>> it's found the right file to exec, it should check that "fred" isn't a
>> directory.  If it is a directory, it should consider that "not found"
>> and the logic would flow through into the checking for ".exe" and
>> whatever other arcane Windows executable-file suffixes make sense.
>>
>> But having not looked at the source, I confess I'm just guessing.
>>
>> Thanks,
>>
>> luke
>>
>>     
>>>> -----Original Message-----
>>>> From: cygwin-owner@cygwin.com
>>>> [mailto:cygwin-owner@cygwin.com] On Behalf Of Luke Kendall
>>>> Sent: Tuesday, April 15, 2008 9:44 PM
>>>> To: cygwin@cygwin.com
>>>> Subject: Directory existence prevents .exe execution
>>>>
>>>> We have the Ici scripting language installed on Windows.  Ici
>>>> expects a
>>>> directory called "ici" to exist alongside, where various
>>>> libraries are
>>>> installedd to provide extra functionality.
>>>>
>>>> Unfortunately, under Cygwin, if w try to run the command "ici" we get
>>>> the error "ici: command not found", because Cygwin chooses to try to
>>>> execute the directory instead of the .exe:
>>>>
>>>> $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr
>>>> bash: /opt/bin/ici: is a directory
>>>> $ ls -ld /opt/bin/ici
>>>> drwxr-xr-x 1 luke Domain Users 0 Oct 17  2005 /opt/bin/ici
>>>> $ ls -ld /opt/bin/ici.*
>>>> -rwxr-xr-x 1 luke Domain Users 233503 Apr 18  2000 /opt/bin/ici.dll
>>>> -rwxr-xr-x 1 luke Domain Users  24576 Jan 29  2003 /opt/bin/ici.exe
>>>>
>>>> I tried naming the ici directory Ici but it made no difference.
>>>> The directory /opt/bin is mounted like so:
>>>> $ mount
>>>> \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system
>>>> (textmode,exec)
>>>>
>>>> Using binmode doesn't help.  Is this a bug, that bash tries
>>>> to execute a
>>>> directory even when there's an executable (with an implicit
>>>> .exe suffix,
>>>> naturally) of the same name in existence ?  If not, can
>>>> anyone suggest a
>>>> workaround?  I can't just append a .exe to the #!/opt/bin/ici shell
>>>> wrapper since then the scripts wouldn't run from Unix.
>>>>
>>>> Is there a bash option that controls this, maybe (I couldn't see one)?
>>>>
>>>> Regards,
>>>>
>>>> luke
>>>>
>>>> --
>>>> 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/
>>>>
>>>>
>>>>
>>>>         
>>>  This message (including any attachments) contains confidential
>>>  and/or proprietary information intended only for the addressee.
>>>  Any unauthorized disclosure, copying, distribution or reliance on
>>>  the contents of this information is strictly prohibited and may
>>>  constitute a violation of law.  If you are not the intended
>>>  recipient, please notify the sender immediately by responding to
>>>  this e-mail, and delete the message from your system.  If you
>>>  have any questions about this e-mail please notify the sender
>>>  immediately.
>>>
>>>       
>>
>> --
>> 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/
>>
>>
>>     
>
>   


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

Re: Directory existence prevents .exe execution

[Larry Hall (Cygwin)]

On 04/17/2008, Luke Kendall wrote:
> Mark J. Reed wrote:
> > I still don't understand why you would put the ici dir in the same
> > place as the ici script.  You can't do that on Unix, so why do it on
> > Cygwin?
> >
> >   
> The creator did this because simply it seemed a convenient way to keep all 
> the ici components together and easy to install and uninstall, and it also 
> caused no problems for the Windows cmd.exe shell.  cmd doesn't try to 
> execute directories as if they were programs.  ici has been around for 
> about 25 years, so it wasn't designed with Cygwin in mind. 

Everything didn't have to be named ici though.  But that's besides the
point.

Cygwin doesn't attempt to execute directories.  It uses stat() to find
out what type of thing "foo" is.  Then it uses that information to
decide how to handle "foo".

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

Re: Directory existence prevents .exe execution

[Luke Kendall]

Larry Hall (Cygwin) wrote:
> On 04/17/2008, Luke Kendall wrote:
>> Mark J. Reed wrote:
>> > I still don't understand why you would put the ici dir in the same
>> > place as the ici script.  You can't do that on Unix, so why do it on
>> > Cygwin?
>> >
>> >   The creator did this because simply it seemed a convenient way to 
>> keep all the ici components together and easy to install and 
>> uninstall, and it also caused no problems for the Windows cmd.exe 
>> shell.  cmd doesn't try to execute directories as if they were 
>> programs.  ici has been around for about 25 years, so it wasn't 
>> designed with Cygwin in mind. 
>
> Everything didn't have to be named ici though.  But that's besides the
> point.
>
And that will probably have to be the solution.
> Cygwin doesn't attempt to execute directories.

What do you mean by Cygwin, in this case?  Bash?  Cygwin's 
implementation of exec()?
>   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).

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.

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!

Cheers,

luke

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

Re: Directory existence prevents .exe execution

[Larry Hall (Cygwin)]

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.

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


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

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

Re: Directory existence prevents .exe execution

[Larry Hall (Cygwin)]

Luke Kendall wrote:
> Larry Hall (Cygwin) wrote:
>> On 04/18/2008, Luke Kendall wrote:
>>> 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 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.

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

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.  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?

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

Re: Directory existence prevents .exe execution

[Luke Kendall]

Larry Hall (Cygwin) wrote:
> Luke Kendall wrote:
>> Larry Hall (Cygwin) wrote:
>>> On 04/18/2008, Luke Kendall wrote:
>>>> 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 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?

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.
>> 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. :-)
>   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.
> 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.

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.

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?

Regards,

luke

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

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

Re: Directory existence prevents .exe execution

[Reini Urban]

2008/4/18, Luke Kendall:
> 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?

Move it to /usr/lib/ici/ or /opt/lib/ici/ where it belongs to. As in
every other distro.
/opt/bin/ici/ is just plain stupid.
-- 
Reini Urban

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

Re: Directory existence prevents .exe execution

[Ross Smith]

Luke, I think the fundamental point that you're missing here is that 
Cygwin is intended to be a subspecies of Unix, not a subspecies of Windows.

I'm not familiar with Ici, but if it currently has both Windows and Unix 
versions, you should expect the Unix version, not the Windows version, 
to be appropriate for Cygwin. If it's currently Windows-only and doesn't 
have a Unix version, it's very unlikely to just work as a native Cygwin 
build without considerable effort. You should expect that porting code 
from Windows to Cygwin will take an effort comparable to porting it to 
Linux.



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

Re: Directory existence prevents .exe execution

[Corinna Vinschen]

On Apr 16 16:42, Luke Kendall wrote:
> Suppose that when it does a stat() on "fred", before it decides that
> it's found the right file to exec, it should check that "fred" isn't a

A stat() call can't know for what purpose it has been called.  Calling
stat on "foo", it will return the information for "foo" first, if it
exists.  Only if it not exists it tries "foo.exe" or "foo.lnk".


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Directory existence prevents .exe execution

[Luke Kendall]

Corinna Vinschen wrote:
> On Apr 16 16:42, Luke Kendall wrote:
>   
>> Suppose that when it does a stat() on "fred", before it decides that
>> it's found the right file to exec, it should check that "fred" isn't a
>>     
>
> A stat() call can't know for what purpose it has been called.  Calling
> stat on "foo", it will return the information for "foo" first, if it
> exists.  Only if it not exists it tries "foo.exe" or "foo.lnk".
>   
Sure, that makes sense.  The stat() call can't know, but the exec() 
certainly does know that it's trying to execute.  So I meant that exec() 
could call stat(), and if the file exists but is a directory, reject it 
as a possible thing to execute, and continue with what I assume is the 
existing Windows-specific logic to look for foo.exe or foo.lnk.

What do you think, does the idea make sense?

Regards,

luke
> Corinna
>
>   


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

Re: Directory existence prevents .exe execution

[Corinna Vinschen]

On Apr 18 13:02, Luke Kendall wrote:
> Corinna Vinschen wrote:
>> On Apr 16 16:42, Luke Kendall wrote:
>>   
>>> Suppose that when it does a stat() on "fred", before it decides that
>>> it's found the right file to exec, it should check that "fred" isn't a
>>>     
>>
>> A stat() call can't know for what purpose it has been called.  Calling
>> stat on "foo", it will return the information for "foo" first, if it
>> exists.  Only if it not exists it tries "foo.exe" or "foo.lnk".
>>   
> Sure, that makes sense.  The stat() call can't know, but the exec() 
> certainly does know that it's trying to execute.  So I meant that exec() 
> could call stat(), and if the file exists but is a directory, reject it as 
> a possible thing to execute, and continue with what I assume is the 
> existing Windows-specific logic to look for foo.exe or foo.lnk.
>
> What do you think, does the idea make sense?

Not to me, no.  Having three files "foo", "foo.exe" and "foo.lnk" in the
same directory is something you should avoid like hell.  The fact that
Windows allows that it just a result of its stubborn suffix-ism.  All of
these files would be called "foo" in a POSIX system and you would have a
name collision.  Sure, you could change exec() to search for a .exe
explicitly, but what's the gain, except for a border case like yours,
which could easily rectified by changing the sources.  You would still
have problems with stat() and other system calls.  I can't see anything
good to hide a problem in one call, exec(), while the problem persists
(and must persist) in other system calls.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: Directory existence prevents .exe execution

[Mark J. Reed]

I still don't get why you want the Cygwin version of ici to work like
the native Windows version.  You have a Unix port - that's what the
Cygwin version should use as a model.  The whole point of Cygwin is to
get Unixy behavior...



On 4/18/08, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> On Apr 18 13:02, Luke Kendall wrote:
> > Corinna Vinschen wrote:
> >> On Apr 16 16:42, Luke Kendall wrote:
> >>
> >>> Suppose that when it does a stat() on "fred", before it decides that
> >>> it's found the right file to exec, it should check that "fred" isn't a
> >>>
> >>
> >> A stat() call can't know for what purpose it has been called.  Calling
> >> stat on "foo", it will return the information for "foo" first, if it
> >> exists.  Only if it not exists it tries "foo.exe" or "foo.lnk".
> >>
> > Sure, that makes sense.  The stat() call can't know, but the exec()
> > certainly does know that it's trying to execute.  So I meant that exec()
> > could call stat(), and if the file exists but is a directory, reject it as
> > a possible thing to execute, and continue with what I assume is the
> > existing Windows-specific logic to look for foo.exe or foo.lnk.
> >
> > What do you think, does the idea make sense?
>
> Not to me, no.  Having three files "foo", "foo.exe" and "foo.lnk" in the
> same directory is something you should avoid like hell.  The fact that
> Windows allows that it just a result of its stubborn suffix-ism.  All of
> these files would be called "foo" in a POSIX system and you would have a
> name collision.  Sure, you could change exec() to search for a .exe
> explicitly, but what's the gain, except for a border case like yours,
> which could easily rectified by changing the sources.  You would still
> have problems with stat() and other system calls.  I can't see anything
> good to hide a problem in one call, exec(), while the problem persists
> (and must persist) in other system calls.
>
>
> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader          cygwin AT cygwin DOT com
> Red Hat
>
> --
> 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/
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Mark J. Reed <markjreed@gmail.com>

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