`zgrep -l` and `zgrep -L` do not appear to work correctly in current Fedora 33 / Rawhide at all. Check this: [adamw@adam c]$ zgrep "U+0033" th.map.gz uz.map.gz uz.map.gz:keycode 4 = U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three that shows that only uz.map.gz contains the string "U+0033", which matches the result of both regular 'grep' after uncompressing the files manually: [adamw@adam uc]$ grep "U+0033" th.map uz.map uz.map:keycode 4 = U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 U+0033 U+2116 Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three Meta_three and a manual inspection of the files. So far, so good. However, let's try out `zgrep -l` (which should print files *with* a match) and `zgrep -L` (which should print files *without* a match): [adamw@adam c]$ zgrep -l "U+0033" th.map.gz uz.map.gz uz.map.gz [adamw@adam c]$ zgrep -L "U+0033" th.map.gz uz.map.gz uz.map.gz er...that's not right. The output of `-l` is correct in this case (though it's wrong in other cases I've tested), but the output of `-L` is clearly wrong - uz.map.gz *does* contain the string, the command should output 'th.map.gz'. It's easy to produce all kinds of broken results by just experimenting with this with various files and strings. this appears to work correctly in current Fedora 32: [adamw@xps13k c]$ zgrep -l "U+0033" th.map.gz uz.map.gz uz.map.gz [adamw@xps13k c]$ zgrep -L "U+0033" th.map.gz uz.map.gz th.map.gz (xps13k is an F32 box). On further investigation, the cause is grep: F32 has grep-3.3-4.fc32.x86_64, F33 and Rawhide have grep-3.4-1.fc33.x86_64. If I downgrade grep to 3.3-4.fc32 on my F33 box, the bug stops happening. I'm attaching sh -x logs from the broken and working cases. You can see somehow the return code of the grep run on line 208 of zgrep is not what it should be. Now, would you like to play a game called "guess how this broken encrypted installs in Russian"? Because it did! :)
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28105#29 looks a lot like the problem here, thus https://git.savannah.gnu.org/cgit/grep.git/commit/?id=0435ebca64fbafcd62008c991dd9377d8a792dfc should be the fix, only the timeframes don't seem to match: that thread claims the behaviour was changed in 3.2, but I see it change between 3.3 and 3.4. I can't see any downstream patches in either build that would affect this. It seems the changes in the post-3.4 patch actually make the code a bit different from how it was in 3.3. So not sure if one of those apparently minor differences is the issue, but hum. I'm going to test patching grep with the apparent fix and see how that goes.
It does seem that that patch fixes things, so I think upstream is just a bit off on the affected versions. One of the lines that's changed in the patch did change between 3.3 and 3.4, so I'm guessing that was the thing that was throwing zgrep off. Now, however, there's another yak to shave: I can't do an official rebuild of grep because the test suite is coredumping on ppc64le and armv7hl. Nothing to do with this patch, it failed the 3.4-3 and 3.4-4 builds also (and 3.3 actually hits the same problem if you try and rebuild it on current F33).
Marking as dependent on the FTBFS bug...
FEDORA-2020-bc38b42372 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
Grr, update shouldn't have automatically closed this bug as it's filed against 33.
FEDORA-2020-81fea835a4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-81fea835a4
FEDORA-2020-81fea835a4 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-81fea835a4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-81fea835a4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-81fea835a4 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-0dcd106c75 has been pushed to the Fedora ELN stable repository. If problem still persists, please make note of it in this bug report.