[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20990: RFC: [PATCH] accept new option: --files0-from=F
From: |
Jim Meyering |
Subject: |
bug#20990: RFC: [PATCH] accept new option: --files0-from=F |
Date: |
Mon, 6 Jul 2015 06:57:19 -0700 |
On Sun, Jul 5, 2015 at 8:32 PM, Jim Meyering <address@hidden> wrote:
> Here is a patch to teach grep the --files0-from=F option.
> That is the same option that is already supported by wc, du and sort
> in the GNU coreutils.
>
> This option allows one to specify NUL-separated file names in the file
> argument, F. When I would receive requests to add this option to other
> programs from the coreutils, I would refuse, because one can obtain
> similar behavior by using xargs like this:
>
> xargs -0 PROGRAM < F
>
> The "use xargs" argument does not work for programs like wc, du and sort.
> In those cases, concatenating the output from multiple invocations
> (as that xargs usage would do) does not result in the same output as
> using --files0-from=F, e.g., because of totals or, for sort, because
> the result cannot be the concatenation of separately-sorted outputs.
>
> For most uses of grep, it would be ok to process separate lists of
> file names in batches and to concatenate the results, but not with
> the --count (-c) option. The count must reflect the total over
> all files processed.
Hmm... *this* --count option does not have that behavior, so it's
not a good justification. This is a per-file and per-output-line count.
> Also, more subtly, consider what would happen when the last batch of file
> name inputs to xargs happens to contain only one name. The output from
> that final invocation of grep (assuming no option like -h or -H) would
> omit the "FILENAME:" prefix for any lines matched from that final file.
And in this case, simply adding '/dev/null' or using -h ensures that
even that unusual case will be handled properly.
Now that I've removed those bits of justification, I'll have to
think more about whether it's worth adding this.