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>
	<BMSMTP8686333710a0207776 AT dlemail DOT itg DOT ti DOT com> <19970711133409718 DOT AAA335 AT TENDLE>
Reply-To:	dbe AT wgn DOT net
Mime-Version:	1.0
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/
-/-' /___/_<_</_</_    Email: dbe AT wgn DOT net
-
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".

- Raw text -