[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: one liner, how do you know which match happened ...



On Wed, Jun 24, 2020 at 12:59:03PM +0200, tomas@tuxteam.de wrote:
> On Wed, Jun 24, 2020 at 12:33:19PM +0200, Albretch Mueller wrote:
> > > "grep -l" will stop at the first hit, so even if you could ask
> > > grep which one of the alternatives it found, it'll miss Hegel
> > > in a file where Kant figures first. Is that what you want?
> > 
> >  Yes, I am fine with that. I include the matches in the Array in a way
> > that the first one is the most important to me anyway, but I need to
> > know which one, which I think should be someone possible, since grep
> > must go through the array using some index, no?

Grep doesn't know anything about "arrays".  Grep is a separate utility,
which has its own specification (from POSIX, which in turn derives from
historical implementations), and GNU grep has its own specific
implementation and extensions.

Grep receives its input from the command-line arguments, and standard
input if no filename arguments are given.  That's all.  It doesn't know
anything else about its parent process's variables, or your intentions.

> OK, if you just want the first hit, there is "--max-count" (aka "-m"),
> which you can use with the combined regular expression. This (given
> the value 1) will spit out the first matching line, which you can
> then post-process to extract the exact match.
> 
> Post-processing is left as an exercise to the reader :-)
> 
> That should be about as fast as "grep -l" can get, take or give.

One small problem here:

       -l, --files-with-matches
              Suppress normal output; instead print the  name  of  each  input
              file  from  which  output would normally have been printed.  The
              scanning will stop on the first match.

You don't *see* the matching line when using the -l option.

Once again, bash and grep are really NOT good choices for this goal,
insofar as I've been able to deduce what the goal is.

If you want to match N files against M strings (or regexes) and collate
them into groups according to which string is first seen in each file,
use a real programming language.  Open each file, then read line by line,
and match each line against each of your input strings, until a match
is found, or you hit the end of the file.  Store results accordingly.

Stop trying to use inappropriate tools.  You're just making your life
harder.


Reply to: