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

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, you type 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.



> > -----Original Message-----
> > From: 
> > [] On Behalf Of Luke Kendall
> > Sent: Tuesday, April 15, 2008 9:44 PM
> > To:
> > 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\\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:
> > Problem reports:
> > Documentation:
> > 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:
Problem reports:

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