Karl Berry wrote: > zgrep: -R: option not supported > > Can't we make it actually work? It would be very useful. Can't we just > pass -r/-R/--recursive to grep, more or less as is done with the other > options? Would you accept a patch?
This is one of those good examples of why file-finding should never have been added to grep. It makes everything more complicated. Since zgrep is simply a wrapper that uncompresses files on the fly and passes it to grep it really wants grep to be a simple filter command. Trying to make zgrep support the entire set of grep's current (and future) directory recursion capability is involved. Think of all of the discussion for grep already about include/exclude capability, what to do about pipes and other special devices and so forth. And as grep changes then the script would need to change in parallel with it to keep in sync. Recreating all of that in the zgrep shell script would be problematic. The reason that -R did not create errors before was that 'grep -R' with stdin does not produce an error. gzip -cdfq | grep -R PATTERN gzip -cdfq | grep -r PATTERN gzip -cdfq | grep --recursive PATTERN Are the same as: gzip -cdfq | grep PATTERN But in none of those cases will grep's directory recursion be known by gzip. So the grep directory recursion options do not work. As such previously the -r option (and -d) was trapped specifically. It would be possible to more easily support a 'find' based directory recursion however. But then the options would not be the set that grep used but would instead be the set that find used. I am not sure that inconsistency would be appreciated and by itself would ellicit more bug reports. Personally I would just trap the -R option as Paul has proposed and report it as an invalid option. If it is useful to provide rationale for this in the man page then I would be willing to try to produce something for it. Bob
