Re: Directory existence prevents .exe execution
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
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
Re: Directory existence prevents .exe execution
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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] -- 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 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
Re: Directory existence prevents .exe execution
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
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/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
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
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
Re: Directory existence prevents .exe execution
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
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
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
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
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http
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/
