From: _kunglao AT prairienet DOT org (Gilligan) Subject: Re: `find' command broken. 12 Jul 1997 10:21:27 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <33C76150.A2F58F7F.cygnus.gnu-win32@prairienet.org> References: <19970711092719531 DOT AAA303 AT TENDLE> <19970711133409718 DOT AAA335 AT TENDLE> <33C6B5BF DOT BA9 AT wgn DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.01 [en] (Win95; I) Original-To: dbe AT wgn DOT net Original-CC: john DOT cooper AT digitivity DOT com, GNU-Win32 AT cygnus DOT com X-Priority: 3 (Normal) Original-Sender: owner-gnu-win32 AT cygnus DOT com $Bill Luebkert wrote: > > John Cooper wrote: > > > > Well, if cygwin32 globs, why doesn't it work under cmd.exe? > > > > H:\ef>dir > > Directory of H:\ef > > 11/07/97 09:48 0 a.c > > 11/07/97 09:48 0 b.c > > 4 File(s) 0 bytes > > 589,430,784 bytes free > > > > H:\ef>find . -name *.c -print > > find: paths must precede expression > > Usage: find [path...] [expression] > > > > H:\ef>find . -name '*.c' -print > > > > H:\ef> > > > > > This will work under bash IFF there are no .c files in the > current > > > directory (bash tries to glob; but since there are no matches, it > leaves > > > it alone) -- in which case, running under cmd should have the > same > > > results). Did you run your tests (cmd vs bash) from the same > directory? > > > > Right. I realize bash globs, but *so does zsh*, and yet `find' > doesn't work > > under zsh. > > > > Could it be that cygwin.dll is somehow doing the globbing for zsh > (even when > > the *.c is in quotes)? > > > > Here's the failure under zsh: > > > > zsh$ find . -name '*.c' -print > H:/ > > /c/gnuwin32/b18/h-i386-cygwin32/bin/find.EXE: paths must precede > expression > > Usage: /c/gnuwin32/b18/h-i386-cygwin32/bin/find.EXE [path...] > [expression] > > zsh$ ls *.c > H:/ > > a.c b.c > > zsh$ > H:/ > > > > Here, (oddly) it works under bash: > > > > bash$ find . -name '*.c' -print > > ./a.c > > ./b.c > > > > The following shows that both zsh and bash pass exactly the same > string to > > the `find' command: > > > > zsh$ echo find . -name '*.c' -print > > find . -name *.c -print > > zsh$ > > > > bash$ echo find . -name '*.c' -print > > find . -name *.c -print > > bash$ > > > > I can only guess that the find command (cygwin32.dll) *knows* that > it's been > > invoked by bash and then doesn't try to do the glob? Under zsh, the > extra > > glob appears to be done by find (cygwin32.dll?) > > I quess I mis-understood the original post, but it's becoming more > clear to me now. > > find will always try to do the glob if it gets the glob characters, > at least one would think it should. So it's up to the shell to > present > the args right to the command. The '*.c' shouldn't be globbed by > the shell, that's why you have to escape it in unix-style shells. > > command.com works (does a globbed find) if I leave the quotes off, > tcsh and bash work if I put the quotes on, which is what you would > expect, except for the gotcha. It only works if there > are no files matching the glob in the current dir (the one you're > sitting in, not the effective starting dir). Strange problem! Globbing works that way, and has for years in the Unix world. If you do: ls -l *.c, the appropriate shell (or is it cygwin.dll?), does the search for any .c files from the current directory, and pastes them into the arguments for the program. So ls (or find, or whatever program) would only see "ls -l a.c b.c" in it's argv[] array. When you then look at the find above, done with globbing and the two .c files, the find command sees "find . -name a.c b.c -print" Now, while find's parsing the command line, it gets to b.c, has no '-' character in front, assumes that it is supposed to be the path since that is the only option that does not have a '-' in front of it. Hence the error "find: paths must precede expression." > It acts like find is globbing the name against the current dir prior > to picking up the args or executing the command. If I knew > where the source for find was, I would take a look at it. That's the way Unix has been, and will always be. On the other hand, some shells allow you to set a variable to disable globbing. I'm not sure if cygwin.dll pays any attention to it. I think it is "set noglob," read the man page of bash to see if it has a similar setting. --- Due to the abundance of spam, the underscore (_) in my return address must be removed for replies to reach me. Spammers leave the _ in. - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".