Re: An appropriate directory search tool?
On Mon 22 Oct 2018 at 10:12:57 (+0900), John Crawley wrote:
> On 21/10/2018 22.48, David Wright wrote:
> > On Sun 21 Oct 2018 at 05:25:05 (-0500), Richard Owlett wrote:
> > > On 10/20/2018 08:16 PM, John Crawley wrote:
> > > > On 20/10/2018 19.28, Richard Owlett wrote:
> > > > > ...I would have expected to use an explicit pipe command
> > > > > between 'find' and 'grep'.
> > > >
> > > > In fact, depending on the exact conditions of your search, you
> > > > might not need to use find at all. 'grep -r' will do a recursive
> > > > search, starting at whatever directory you give it, looking inside
> > > > every file for some content. Like:
> > > >
> > > > grep -r 'keyword_or_regex' dirname
> > > >
> > > > Of course, 'man grep' for various options...
> > > >
> > >
> > > I wish a list of files with a specific extension in a directory which
> > > contain keywordA but not keywordB. Recursing down the directory tree
> > > was the primary objection to the MATE search tool.
> >
> > At last, a direct question!
> >
> > $ grep -L keywordB $(grep -l keywordA a-directory/*extension)
> >
> > Mix with quotes according to taste and needs.
>
> I'm pretty sure David's code above will do exactly what the OP asked for.
>
> This is about searching through a list of files, so I think the
> subsequent discussion of stdin might have been a bit confusing, since
> it's only one file.
I was only trying to demonstrate the side-effect of stopping on stdin,
not the continuation of scanning other files, which I had already
pointed out.
> The -L and -l options are about what grep outputs: the name of a file,
> not the matching string itself.
>
> Man grep's "The scanning will stop on the first match" refers to
> scanning inside a certain file; so once a decision has been reached as
> to whether it satifies the condition or not, then grep will move on to
> testing the next file.
Yes, continuing to test further files is implied by the plural "files"
in the options' names. Stopping after the first match gives an obvious
efficiency gain which need not necessarily have been documented¹.
In the case of stdin, however, stopping after a match has an important
side effect that does mean it *needs* to be documented. Omitting it
would be a bug.
Perhaps it was unwise, though, to suggest a practical demonstration
using stdin. I hadn't realised how little the questioner understood
about using stdin in that manner.
¹ For example, does grep need to open a file whose length is shorter
than the string being sought? Does it need to document whether it
skips opening it? Will a user complain because the file's last-access
time is not updated if grep doesn't open it? Perhaps not. (Of course,
stdin would not be affected in this particular case as its length is
undefined.)
Cheers,
David.
Reply to: