Subject: Re: `find' command broken.
From: [email-masked] ("$Bill Luebkert")

11 Jul 1997 19:29:20 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
References: <19970711092719531.AAA303@TENDLE>
		<[email-masked]> <19970711133409718.AAA335@TENDLE>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01Gold (Win95; I)
Original-To: [email-masked]
Original-CC: [email-masked]
Original-Sender: [email-masked]

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: [email-masked]
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".