This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: grep -i -R path32 * vs grep -i -R path32 *.vb*


Sheryl,

I think it would really benefit you to peruse the info files for find and
grep very carefully.  I suggest installing 'pinfo', a replacement for
info, since it has a better interface, and allows you to view manpages as
well, but 'info find' and 'info grep' should do just as well.

In particular, you would find that the exact syntax for the -exec option
to find is '-exec command arguments ;', and that the '\' is needed to
escape the semicolon for the shell (in my case - bash).  Since ';' is not
a special character in the Windows command shell, it doesn't need to be
escaped.  Thus, 'find -name "*.vb*" -exec grep -Hni path32 {} ;'
should work.  Note that the '*' is a special character in the command
shell, and does need to be quoted (I don't think the shell uses '\' to
escape characters).

Piping the output of find to grep is useless for what you're trying to do,
since you are effectively searching for 'path32' in the file *names*.  If
you wanted to run grep on the *contents* of the files, you should have
used xargs ('[p]info xargs' for details).  It might also be worth the
effort to look into the -print0 find option and the -0 xargs option.

There is no surprise that find understands the ".", as you say, since what
the -name option does is look at the directory entries, and in Windows,
the short (8.3) filenames always have an implicit dot.

Grep's --include does effectively the same as find's -name, i.e. it looks
through the directory entries and tries to match them with the given
patttern.  The reason it works and simply specifying the pattern doesn't
is that when you specify the pattern alone, the shell tries to expand it.
Since you apparently don't have any '*.vb*' files in your current
directory, the shell gives up and leaves the wildcard pattern as it is,
and then grep tries to expand it, with the same result.  This also
explains why the unquoted parameter to --include works - the shell will
not expand the pattern, so grep gets it unchanged.  If you actually had a
'*.vb*' file in your current directory, grep would also get confused until
you quote the pattern (i.e., 'grep -R -i --include="*.vb*"').

Maybe we should have an FAQ entry describing the quoting differences
between the command shell and sh/bash/tcsh/<your favorite shell here>?
I'll see if I can write something...

Oh, and lastly, grep is a search utility, and, whatever the animosity
between the GNU developers and Microsoft (and I'm not aware of too much -
don't all jump on me at once ;-)), I don't think it singles out Visual
Basic files for special processing... :-D
	Igor

On Wed, 9 Oct 2002, Sheryl McKeown wrote:

> Hi Igor,
>
> I too am an avocate for find. However, I can't seem to
> master it's usage in XP's shell.
>
> For instance, the find command you suggested
>
> "find . -name *.vb* -exec grep -ni path32 {} \;
> -print"
>
> returns the error
> find: missing argument to `-exec'
>
> in the XP shell.  The command works fine in the bash
> shell.
>
> More on the XP shell...
> The command
> find . -name *.vb* -exec grep -ni path32 {} \;
> also errors.
> find: missing argument to `-exec'
>
> And interestingly enough, find 'understands' the .
>
> find . -name "*.vb*" returns the correct files.
> "find . -name "*.vb*"
> ./IntelliLab/IntelliLab.vbp
> ./IntelliLab/IntelliLab.vbw
> ./IntelliLab/IntelliLabR.vbp
> ./IntelliLab/IntelliLabR.vbw
> ./LabTestMnt/LabTestMnt.vbp
> ./LabTestMnt/LabTestMnt.vbw
> ./MasterProjectGroup.vbg
> ./Ordent/ordent.vbp
> ./Ordent/ordent.vbw
> ./QC/qc.vbp
> ./QC/QC.vbw
> ./Reports/Reports.vbp
> ./Reports/Reports.vbw
> ./RsltsEnt/RsltsEnt.vbp
> ./RsltsEnt/RsltsEnt.vbw
> ./RsltsInqry/ptresinq.vbp
> ./RsltsInqry/Ptresinq.vbw
>
> It vaguely makes sense that the . when specified as a
> wildcard vs a . as specified as part of a file name.
>
> But when this command is either piped or -exec to grep
> I get nothing.  Not even an error.
>
> 16:47 0  [C:IDATAILAB]
> .find . -name "*.vb* |grep -i path32
>
> 16:47 0  [C:IDATAILAB]
> .find . -name "*.vb* -exec grep -i path32{} ;
>
>
> The grep command you suggested
> grep -i -R path32 --include=*.vb* .
> does work.
>
> But that leads me to ask why I have to use the
> --include.  What is the difference between
> --include=*.vb* and *.vb*?
>
> Maybe it's because I'm searching Visual Basic files.
> _grin, wink_
>
>
> Additional comments and explanations welcome,
> Sheryl
>
> --- Igor Pechtchanski <pechtcha@cs.nyu.edu> wrote:
> > On Wed, 9 Oct 2002, Sheryl McKeown wrote:
> >
> > > Better titled, "That dot thing again on Windows XP
> > > Pro..."
> > >
> > > Ok, again I'm trying to search recursively through
> > a
> > > directory structure looking for specific values.
> > >
> > > According to grep --help grep -R should walk the
> > > directory structure.  Cool.
> > >
> > > So, "grep -i -R path32 *" returns, as expected,
> > > .grep -i -R path32 *
> > > IntelliLab/IntelliLab.vbp:Path32="..Build"
> > > IntelliLab/IntelliLabR.vbp:Path32="..BUILD"
> > > IntelliLab/intellilabr.vbpold:Path32="Build"
> > > LabTestMnt/LabTestMnt.vbp:Path32="..BUILD"
> > > Ordent/ordent.vbp:Path32="..BUILD"
> > > QC/qc.vbp:Path32="..BUILD"
> > > Reports/Reports.vbp:Path32="..BUILD"
> > > RsltsEnt/RsltsEnt.vbp:Path32="..BUILD"
> > > RsltsInqry/ptresinq.vbp:Path32="..BUILD"
> > >
> > > But I want to search only files with a specific
> > > extension.  Enter the dot thing.  So I try
> > > grep -i -R path32 *.vb*
> > > which returns nothing.
> > >
> > > I understand that the directories, technically, do not
> > > have a . in the name, therefore they won't be
> > > searched.  The same reason grep -i -R path32 *.*
> > > returns nothing.
> > >
> > > So the question becomes, how do I grep a directory
> > > structure and search only files with a specific name.
> > > (I prefere a grep only solution vs "find . -name
> > > "somefilename" -exec ...).
> > >
> > > Thanks,
> > > Sheryl
> >
> > Sheryl,
> >
> > This isn't a "dot problem".  This is a grep usage
> > problem.
> >
> > Frankly, I don't see why you are so opposed to 'find'...  'find .
> > -name *.vb* -exec grep -ni path32 {} ; -print' can be a very powerful
> > tool. If you want the filenames printed before the matches (ala 'grep
> > -R'), consider using 'find . -name *.vb* -print | xargs grep -i
> > path32'.  If you have files with spaces and weird characters, try
> > 'find . -name *.vb* -print0 | xargs -0 grep -i path32'.
> >
> > Of course, if you really want to stick with "pure grep", you could
> > always do 'grep -i -R path32 --include=*.vb*' (now that I've pitched
> > in an argument in favor of "find" :-D)...  'info grep' should also be
> > quite helpful.
> >       Igor

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]