Re: `find' command broken.

[Gilligan <_kunglao at prairienet dot org>]

$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@cygnus.com" with one line of text: "help".