From: dbe AT wgn DOT net ("$Bill Luebkert") Subject: Re: `find' command broken. 11 Jul 1997 19:29:20 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <33C6B5BF.BA9.cygnus.gnu-win32@wgn.net> References: <19970711092719531 DOT AAA303 AT TENDLE> <19970711133409718 DOT AAA335 AT TENDLE> Reply-To: dbe AT wgn DOT net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (Win95; I) Original-To: john DOT cooper AT digitivity DOT com Original-CC: GNU-Win32 AT cygnus DOT com Original-Sender: owner-gnu-win32 AT cygnus DOT com 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! 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. -- ,-/- __ _ _ $Bill Luebkert (_/ / ) // // DBE Collectibles / ) /--< o // // http://www.wgn.net/~dbe/ -/-' /___/_<_