> Thanks for the suggestion. You're right, this would be better than zgrep > etc. > > I have some qualms though, as the new option would increase the attack > surface for 'grep', in that you could then execute arbitrary code by > passing certain options to 'grep'. Is there some safer way to get what > you want?
There is still the possibility of including the respective compression libraries directly in grep and using the `-Z` and `-J` as proposed, but this wouldn't allow to use less popular compression algorithms. One possibility, but I'm not sure what it's worth, would be to give grep a special arg0 to enable shell commands, like `jgrep zcat pattern123 file.gz`. But I'm not sure if it's worth the trouble. > One supposes that if the file extension is not trustworthy, one can taste > file like the file command, and use libraries like the gzip libraries to > handle gzipped files as a stream. There are so many others: zip files could > be treated like directories and all the files in them that match the glob > could be searched, and then there is bzip2, 7zip, .... It becomes a > popularity contest! One can do all this with shell scripting, and leave poor > old grep out of it! The reason why I wanted to do this in grep directly is because it's difficult to implement this with shell scripting. I noticed that neither zgrep, bzgrep nor xzgrep support the `-r` option, among others, presumably because it's too difficult to implement in a portable way. I made my patch use a shell command specifically to provide maximum flexibility with minimum maintenance cost. But it does open the door to security risks, so I understand if it's not worth adding to grep.
