Re: Is this a bug or a behavior?
On 02/15/2013 11:46 AM, Larry Hall (Cygwin) wrote: I believe these questions are the crux of your inquiry so I've stripped out the surrounding details. Apologies if you feel I've removed something you feel is a significant point. This goes to the heart of a difference between how Windows and Linux treat executables and various ingrained assumptions both make about their respective expectations (essentially what Adam said ;-) ). Cygwin does try to bridge this gap but it has its limits as well. This is actually not new issue and has been discussed many times in the past on this list. If you're interested in the details or, even better, in improving what's currently implemented, I'd recommend reviewing previous discussions, the ideas they generated, and the issues and limitations mentioned. That should help you understand the current state and provide you with an informed basis if you want to take a swing at providing some patch. The only short answer I can give you is that the current state is a compromise. That doesn't mean there isn't a better one. Just that it's a complicated area for many reasons so getting to a better state is also complicated. Fair enough. I'd like to take a crack at it once I clear some other things off of my plate first. Will have to look through previous conversations before I know if it's something I can competently tackle. Thanks. -jack- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is this a bug or a behavior?
On 2/15/2013 12:29 AM, Centrych Administrator wrote: snip How can it ever be consistent while 'filename' and filename.exe' are allowed to exist in the same directory? Is there some way to differentiate between a Windows .exe and a Cygwin binary, like grep.exe, that's intended to execute within the Cygwin environment? I believe these questions are the crux of your inquiry so I've stripped out the surrounding details. Apologies if you feel I've removed something you feel is a significant point. This goes to the heart of a difference between how Windows and Linux treat executables and various ingrained assumptions both make about their respective expectations (essentially what Adam said ;-) ). Cygwin does try to bridge this gap but it has its limits as well. This is actually not new issue and has been discussed many times in the past on this list. If you're interested in the details or, even better, in improving what's currently implemented, I'd recommend reviewing previous discussions, the ideas they generated, and the issues and limitations mentioned. That should help you understand the current state and provide you with an informed basis if you want to take a swing at providing some patch. The only short answer I can give you is that the current state is a compromise. That doesn't mean there isn't a better one. Just that it's a complicated area for many reasons so getting to a better state is also complicated. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is this a bug or a behavior?
On 02/13/2013 11:55 AM, Adam Dinwoodie wrote: Yes. If you ask for a file, the file doesn't exist, but the file with a .exe extension exists, Cygwin will refer you to the .exe version of the file. See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-exe. Thanks, already aware of that, and it's why I raised this question. From that point of view it is; Cygwin is self-consistent, but the very nature of attempting to write a Linux-like interface on a fundamentally non-Linux like OS means such issues can't be avoided. I'm not clear on what your standard for self-consistent is, or why filenames are an interface issue. Those aside, consider these two lines: $ rm -rf * mkdir a touch grep cp grep /bin/grep a $ rm -rf * mkdir a touch grep cp /bin/grep grep a The first line executes as expected while the second, which reverses the order of files, fails after copying the .exe with the following: cp: cannot create regular file `a/grep': File exists Now, take these two sets: $ rm -rf * touch foo grep cp /bin/grep.exe . $ mv foo grep ls -i $ rm -rf * touch foo cp /bin/grep.exe . $ mv -n foo grep The first set works as expected while the second deletes grep.exe during the rename even though no-clobber is explicitly passed to mv. Nobody has yet suggested a more consistent alternative that still allows, for example, a Linux shell script that calls unadorned grep to work on Cygwin. How can it ever be consistent while 'filename' and filename.exe' are allowed to exist in the same directory? Is there some way to differentiate between a Windows .exe and a Cygwin binary, like grep.exe, that's intended to execute within the Cygwin environment? For your (I really hope) contrived example... Unfortunately, it wasn't contrived. It was an actual question in a BASH scripting module that I unnecessarily have to slog through. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Is this a bug or a behavior?
Jack Radigan wrote: Using the following script: #!/bin/bash set -x cat eof | `ls /bin | grep ^grep$` alpha alpha omega eof Easier repro showing this phenomena: ls /bin | grep '^grep$' On Linux, you'll get grep as output. Cygwin won't output anything. But, the command 'cp /bin/grep ~/.' will copy grep.exe to my home directory. Yes. If you ask for a file, the file doesn't exist, but the file with a .exe extension exists, Cygwin will refer you to the .exe version of the file. See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-exe. Shouldn't 'ls' be suppressing the '.exe' extension for cygwin binaries in the same way that 'cp' appends it? No: ls tells you about what files actually exist. grep.exe exists; grep doesn't. Seems inconsistent not to. From that point of view it is; Cygwin is self-consistent, but the very nature of attempting to write a Linux-like interface on a fundamentally non-Linux like OS means such issues can't be avoided. Nobody has yet suggested a more consistent alternative that still allows, for example, a Linux shell script that calls unadorned grep to work on Cygwin. If this is causing you a real problem that you can explain, the list may be able to give you some assistance working around it. For your (I really hope) contrived example, replace the command substitution with /bin/grep for a script that will work on both Linux and Cygwin. -- Adam Dinwoodie Messages posted to this list are made in a personal capacity. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is this a bug or a behavior?
On Wed, Feb 13, 2013 at 04:55:01PM +, Adam Dinwoodie wrote: Jack Radigan wrote: Using the following script: #!/bin/bash set -x cat eof | `ls /bin | grep ^grep$` alpha alpha omega eof Easier repro showing this phenomena: ls /bin | grep '^grep$' On Linux, you'll get grep as output. Cygwin won't output anything. Yep, but if you want to write code that will work on both *nix and Cygwin you could do this: ls /bin | sed -n -e 's/\.exe$//' -e '/grep/p' That works on both Cygwin and Linux. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
