This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: grep -i -R path32 * vs grep -i -R path32 *.vb*
- From: Sheryl McKeown <iboulder at yahoo dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 10 Oct 2002 09:33:38 -0700 (PDT)
- Subject: Re: grep -i -R path32 * vs grep -i -R path32 *.vb*
- Reply-to: smckeown at mac dot com
Igor and All,
Thanks for your comments and explanations on ., grep,
find, and VB file processing.
And thanks for the pointers to the info files. I'll
take a close look and them.
Also, you are right in that the ; does not have to be
escaped in the XP shell (cmd.exe). That was my error,
and indeed the command works as advertised.
Best,
Sheryl
--- Igor Pechtchanski <pechtcha@cs.nyu.edu> wrote:
> 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/
>
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
--
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/