+++ This bug was initially created as a clone of Bug #121514 +++ Al Viro posted to vendor-sec on Apr22: zgrep contains the following gem: for i do [snip] if test $with_filename -eq 1; then sed_script="s|^[^:]*:|${i}:|" else sed_script="s|^|${i}:|" fi $grep $opt "$pat" | sed "$sed_script" [snip] done Aside of the correctness issues (try to use zgrep on files with e.g. '&' in names), it leads to obvious fun when zgrep arguments had been obtained by globbing in an untrusted place. Even with standard sed we have at least ;w<filename>; to deal with; for GNU sed there's also ;e; on top of that (execute the contents of pattern space). bzgrep is no better - it's based on zgrep. AFAICS, there are two solutions - one is to do what *BSD had done and make grep(1) use zlib and libbz; then zgrep et.al. become links to grep. Another is to quote \, |, ; and newlines, which means extra invocation of sed(1)... Also affects RHEL2.1, RHEL3
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-474.html
I am having a problem reconciling the bzip2-1.0.2-bzgrep.patch in an errata srpm created for this bug (bzip2-1.0.2-11.EL3.4.src.rpm) and the same patch file in the srpm created for Fedora Core 3 (bzip2-1.0.2-13.FC3.1.src.rpm). Line 8 of the bzip2-1.0.2-bzgrep.patch (dated Jun 7 07:12) in the RHEL 3 srpm reads: + j=${i//\\\\/\\\\} but line 8 of bzip2-1.0.2-bzgrep.patch (dated Jun 8 10:08) in the FC 3 srpm reads: + j=${i//\\/\\\\} Is one of these patch files incorrect? And if so, which one?
Please see attachment #118434 [details], from bug #158801. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SHA1sum of the attachment: 09e992a0e6bb50fa7387f927041a50994b4555c8 test-cases.tar.gz Did a little testing on bzgrep. Test scripts are in the attached "test-cases.tar.gz". Just untar the tarball, go to the test-cases/ directory and run: $ ./doit.sh That will display the results of RHEL 3's bzgrep and FC3's bzgrep on two test files (one of which has an embedded backslash in its filename) and pipe the bzgrep results into less. My take on this is that the RHEL 3 bzgrep patch is more correct than the FC3 patch. In the FC3-patched version of bzgrep, the `\f' in the file- name gets converted into a form-feed (^L) in the display lines, but in the RHEL 3 version, the `\f' displays as `\f'. The bash interpretation of ${variable//<pattern>/<replacement>} is certainly not as intuitive as one might wish! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFDGntvxou1V/j9XZwRAo5pAJ9rv1IYXPQlCLyEZeIAvbOxZL4uVACgoozo vVG9Vhmow55/TRUFZYcTQgU= =My5q -----END PGP SIGNATURE-----
The rhel4 version was not fixed properly - there is a typo in the patch ( the command j=`printf "%s" "$i" | tr '\n' ' '` should be j=`printf "%s" "$j" | tr '\n' ' '` ). So this bug is still present in rhel4. I'm reopening this bug. The test case is: Create two bz2 archives one of them with name |; s|.*|echo bla 1>\&2|e; s|:|.bz2. and use bzgrep command which will find some string in the previously mentioned file.