Re: bug-grep Digest, Vol 6, Issue 71

[Dave B]

Edward Peschko wrote:

>> Obviously by my response I don't think something like that is needed.
>> Is there a reason that you can't use one of the several existing
>> methods?  Can you provide some examples where not having this feature
>> is significantly problematic?
>>
> 
> Sure..
> 
> 1: suppose I want to build a 'project' file, which contains a list of
> files that I care about - one that avoids temporary files, binary
> files, etc. This would then be a very nice feature.

You can use xargs to obtain pretty much the same effect.

xargs grep pattern < filelist.txt

(with the usual issues to consider when using xargs)

> 2. suppose - in this file, I want to pass commands to grep (in the
> form of config flags, or something more fancy. Then this is a very
> nice feature.

You can set the environment variable GREP_OPTIONS with the flags you like.

> 3. even with the find solution you are opening up multiple grep
> processes per file which costs time. This feature avoids that overhead.

It wouldn't be multiple grep processes per file, it would be "just" one grep
process per file. But read on...
If you look carefully, you'll see that he used find ... -exec grep .. +
The plus at the end is very important. It's what allows to run a single
instance of grep with as many arguments as possible, as opposed to run one
grep per file.

> In any case, the 'arg list too long' problem being solved in
> new versions of linux doesn't help me because it isn't cross
> platform.

Neither are the grep flags you use below, unless you're sure you have GNU
grep available on every system where your script runs.

> 
> Ultimately, I have something like this in mind in the filelist I
> wish to pass to grep:
> 
> -n
> --expand-gzip
> --expand-tar
> /file1
> /file2
> /file3.tar.gz
> 
> or more fancy:
> 
> -n
> <helper_command>:  /file1
> <helper_command>: /file2
> 
> where helper command is a command that is
> run on the file contents of /file1 before
> being passed to grep..
> 
> Anyways, that's ok, I've implemented a bit hacky
> way of doing this, so if it's unacceptable to
> have this in the core, I have a workaround.

Note that I'm not against the idea you propose, in principle; whether that's
a good or bad idea is probably open to depate, and the opinions of the
developers are to keep into consideration. More simply, I was just trying to
give you some ideas on how to implement what you want.

-- 
D.