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

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

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.


On 4/16/08, Luke Kendall <> 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, 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-----
[] On Behalf Of Luke Kendall
Sent: Tuesday, April 15, 2008 9:44 PM
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

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



Unsubscribe info:
Problem reports:

 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

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Unsubscribe info:
Problem reports:

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