Description of problem: zless on Fedora 36 PreRelease does not work with gzipped text files. A dnf filelist gzipped file was attempted to be viewed with zless. zless stated the file was "binary" and asked to view it anyway. Version-Release number of selected component (if applicable): How reproducible: Use "zless filename.gz" to view a "filename" that should be text (for example gzipped xml), zless fails to uncompress through gzip and tried to view the gz file directly showing binary data. Steps to Reproduce: 1. use zless on Fedora 36 to view a gzipped text file, for example a dnf filelist.xml.gz 2. zless 7eec258c5aee56524c63da094fa8bd9c41b859f58a80f4356e92e9d438c88d74-filelists.xml.gz 3. Actual results: zless displays that the file is binary and asks to display it anyway "7eec258c5aee56524c63da094fa8bd9c41b859f58a80f4356e92e9d438c88d74-filelists.xml.gz" may be a binary file. See it anyway? Expected results: zless should uncompress the file through gzip and display the resulting plain text in a readable way Additional info: zless is a subcomponent of 'gzip' package, the version of gzip on Fedora 36 for this report was gzip-1.11-2.fc36.x86_64 To debug, the /usr/bin/zless script was modified to echo the values of : echo "LESSOPEN: $LESSOPEN" echo "check_exit_status: $check_exit_status" echo "use_input_pipe_on_stdin: $use_input_pipe_on_stdin" after the "LESSOPEN" export but before the call to exec less "$@" the values of those three were: LESSOPEN: ||-gzip -cdfq -- %s check_exit_status: | use_input_pipe_on_stdin: -
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Hello, seems to work on my system (f37), are you still able to reproduce this? Installed Packages Name : gzip Version : 1.12 Release : 2.fc37 Architecture : x86_64 Size : 381 k Source : gzip-1.12-2.fc37.src.rpm [jamartis@jamartisT480s tmp]$ cat foo.xml <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note> [jamartis@jamartisT480s tmp]$ gzip foo.xml [jamartis@jamartisT480s tmp]$ zless foo.xml.gz <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note>
No, still broken here and I upgraded to Fedora 38 official $ cat /etc/os-release NAME="Fedora Linux" VERSION="38 (KDE Plasma)" ID=fedora VERSION_ID=38 VERSION_CODENAME="" PLATFORM_ID="platform:f38" PRETTY_NAME="Fedora Linux 38 (KDE Plasma)" .... 04/26 10:31 [mos@asus ~]$ cat rsync_exclude .cache/ Downloads/ isos/ junk/ kernel/ koji/ .local/ local/ .nv/ rpms/ .p2/ 6.2.12-300.fc38 wayland 04/26 10:31 [mos@asus ~]$ gzip -c rsync_exclude > rsync_exclude.gz 6.2.12-300.fc38 wayland 04/26 10:31 [mos@asus ~]$ file rsync_exclude.gz rsync_exclude.gz: gzip compressed data, was "rsync_exclude", last modified: Sun Oct 23 03:23:22 2022, from Unix, original size modulo 2^32 76 6.2.12-300.fc38 wayland 04/26 10:31 [mos@asus ~]$ gzip -tv rsync_exclude.gz rsync_exclude.gz: OK 6.2.12-300.fc38 wayland 04/26 10:31 [mos@asus ~]$ zless rsync_exclude.gz "rsync_exclude.gz" may be a binary file. See it anyway? 1 ^_<8B>^H^H<AA><B3>Tc^@^Crsync_exclude^@<D3>KNL<CE>H<D5><E7>r<C9>/<CF><CB><C9>OL)<D6><E7><CA>,<CE>^G<92>Y<A5>y<D9><FA>\٩Ey<A9>9@: 1 ?+S<9F>K/'?9^QȃRzye<FA>\E^E<B9>@<D5>z^EF<FA>\^@{<8E>{<D8>L^@^@^@
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening against Fedora 38 since comment #3 [https://bugzilla.redhat.com/show_bug.cgi?id=2080014#c3] shows it's also a bug on that version
This is still a problem in Fedora 39: cat /etc/os-release NAME="Fedora Linux" VERSION="39 (KDE Plasma)" ID=fedora VERSION_ID=39 VERSION_CODENAME="" PLATFORM_ID="platform:f39" PRETTY_NAME="Fedora Linux 39 (KDE Plasma)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:39" DEFAULT_HOSTNAME="fedora" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f39/system-administrators-guide/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=39 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=39 SUPPORT_END=2024-11-12 VARIANT="KDE Plasma" VARIANT_ID=kde $ zless --version zless (gzip) 1.12 // sample text file containing Firefox about:config settings $ cat test.txt # useful about:config settings browser.link.open_newwindow.override.external 3 browser.link.open_newwindow.restriction 0 browser.search.openintab true browser.sessionstore.interval 3600000 browser.sessionstore.platform_collection false browser.sessionstore.restore_on_demand false browser.sessionstore.restore_tabs_lazily false browser.sessionstore.resume_from_crash false browser.tabs.loadBookmarksInBackground true browser.tabs.loadBookmarksInTabs true $ gzip -c test.txt > test.txt.gz $ file test.txt* test.txt: ASCII text test.txt.gz: gzip compressed data, was "test.txt", last modified: Sun Jan 14 20:40:23 2024, from Unix, original size modulo 2^32 456 $ zless test.txt.gz "test.txt.gz" may be a binary file. See it anyway? 1 ^_<8B>^H^H<B7>F<A4>e^@^Ctest.txt^@<8D><D0>Mk<C3>0^L^F<E0>s<F6>+^B<BB><9B><C2>`<87>^]{<DB>}w<A3><D8>Jj<A2>HE<92><9B>n<BF>~<CE>:<CA>^F݇.^F<E9>Az<F1>}_^M<C7>J=^LR<FD>) <8F>e<EA>^M<DD>^KOv7 1 <A8><AC><86>^Z<A8><F0>^\<E4><88>^\^Yp<96>5<C8> UKƀgGe<A0><EE><E1>W<AF>h<AE>%y^Q<EE>vW<9A>^N^_<B6><B0><C3>йV<FC>25k<DE>\^TC<9B><A3><9E><B6>;<8F><BB><AD>n<AB>#<81><8F><A2>KLB<84><97>s#<90> 1 <FD><B0>tK<D5><DE>(^\3.<C0><F9>?<B8><E5><B4>H<F0>V<E8><F5>^O^^W<8C><A3>JK<A3>`<87>O|<D5>۞@^By/2/<A0><B3>=<F3>^^<D2><<A9>Ԗ<E4><DB>Wܲ/<AD>wQ<EF><87>q<D4>p<C8>^A^@^@
I was wondering if the user the zless runs on matters, the original tests were with my personal user (mos). If I make a clean user from scratch: sudo useradd testuser sudo passwd testuser (set a a password) sudo -i -u testuser then run the same test, the zless works correctly for this "testuser" user. This makes no sense to me because the "LESSOPEN" in both environments are exactly the same: testuser@msi:~$ echo $LESSOPEN ||/usr/bin/lesspipe.sh %s mos:~ [2047]$ echo $LESSOPEN ||/usr/bin/lesspipe.sh %s under Fedora, the LESSOPEN is set for all bash users from /etc/profile.d/less.sh , so it makes sense that 'testuser' and 'mos' have the same LESSOPEN /etc/profile.d/less.sh:5:if [ -z "$LESSOPEN" ] && [ -x /usr/bin/lesspipe.sh ]; then /etc/profile.d/less.sh:7: export LESSOPEN="||/usr/bin/lesspipe.sh %s" ******* SOLUTION ******* By doing this "env | sort > testuser.env" for the testuser and my personal user "env | sort > mos.env" and comparing the two with sdiff, I've found 2 differences that are related to less: $ sdiff -sw200 /tmp/testuser.env /tmp/mos.env |grep -i less > LESS=-igNRX > LESSSECURE=1 The "testuser" works correctly because it does not set export LESSSECURE=1 my 'mos' user does set LESSSECURE=1 from my .bashrc because in general in development I don't want to risk changing files from less. When I remove LESSSECURE from my environment and run "zless test.txt.gz" again it works. I'm not sure why, but somehow gzip/less can't do zless if less is in SECURE mode. I don't know if it should be expected behavior and correct for "zless" to fail if LESSSECURE is 1
I've found the below function in my .bashrc allows "zless filename" to work while I can continue to set LESSSECURE in my .bashrc function zless() { # $1 is the filename, e.g. test.txt.gz # env -u LESSSECURE bash -c "/usr/bin/zless $1" } But a simple fix in "gzip" package itself (ie fix the issue in general) would be simply to unset LESSSECURE just before the 'exec' call in the /usr/bin/zless script: LESSOPEN="|$check_exit_status${use_input_pipe_on_stdin}gzip -cdfq -- %s" export LESSOPEN unset LESSSECURE <<< add here exec less "$@"
A question to me is, should 'zless' break if someone decided to set LESSSECURE=1 I would think that's a "no" and this should be fixed
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
I've reopened this to Fedora 39, when tested on Fedora 39 with gzip-1.12-6.fc39.x86_64 this fails (zless only works if LESSSECURE is not set to 1) head .bashrc > test.txt gzip -c test.txt > test.txt.gz echo $LESSSECURE (blank == LESSSECURE not set) zless test.txt.gz .cache/ Downloads/ isos/ junk/ kernel/ koji/ .local/ local/ .nv/ rpms/ export LESSSECURE=1 zless test.txt.gz "test.txt.gz" may be a binary file. See it anyway? 1 ^_<8B>^H^HeY:f^@^Ctest.txt^@<D3>KNL<CE>H<D5><E7>r<C9>/<CF><CB><C9>OL)<D6><E7><CA>,<CE>^G<92>Y<A5>y<D9><FA>\٩Ey<A9>9@:?+S<9F>K/'?9^QȃRzye<FA>\E^E<B9>@<D5>^@<84><B2>E 1 <F7>G^@^@^@ zless should not break when LESSSECURE happens to be set to 1
PS, the input test file was my rsync_exclude file not the head of .bashrc but the test is still valid. I did several different tests one using the head of .bashrc as text and one using an rsync exclude file, but pasted the wrong code. This is the test all over: head .bashrc > test.txt gzip -c test.txt > test.txt.gz unset LESSSECURE zless test.txt.gz # .bashrc # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi # command line logout of user from KDE5+ # qdbus org.kde.Shutdown /Shutdown logout # qdbus org.kde.Shutdown /Shutdown logoutAndReboot export LESSSECURE=1 zless test.txt.gz "test.txt.gz" may be a binary file. See it anyway? 1 ^_<8B>^H^H<D6>[:f^@^Ctest.txt^@<8D><8C>=^K<C2>@^PD<FB><FD>^U^C)<C5>Kee%hegJ<B1><C8><DD><ED>%<87><97>]<BC>^O<FC><FB>^F^Bb<E9>T^C<F3><DE>t0v,sv<D4>aЖ^]cJj<C7>^D<CF>!J 1 <AC>Q<A5>^Pŀ;<F6>^A=W<D7>o^B^^Gԙ<85><B0><C6><FC>.^T"<AD>wN<97>e^T<8F>^T<85><91>t<D2>V<A1>^A<AD>pFȺ<E0>z<BE>^\v+<F8><F2><B6>^Uh<9E><CC>ӳ^Y<E6>V<BD><BE>^E<FD><B7>m<F2> 1 <FF><E4>I<FC><8D><AD>j<A5>^O<U+E65C>l<DF>^@^@^@
Note that the bug is that envir var "LESSSECURE" being defined breaks zless, not that zless doesn't work at all. Try this next time: export LESSSECURE=1 zless foo.xml.gz (In reply to Jakub Martisko from comment #2) > Hello, > > seems to work on my system (f37), are you still able to reproduce this? > > Installed Packages > Name : gzip > Version : 1.12 > Release : 2.fc37 > Architecture : x86_64 > Size : 381 k > Source : gzip-1.12-2.fc37.src.rpm > > > > [jamartis@jamartisT480s tmp]$ cat foo.xml > <note> > <to>Tove</to> > <from>Jani</from> > <heading>Reminder</heading> > <body>Don't forget me this weekend!</body> > </note> > > [jamartis@jamartisT480s tmp]$ gzip foo.xml > [jamartis@jamartisT480s tmp]$ zless foo.xml.gz > <note> > <to>Tove</to> > <from>Jani</from> > <heading>Reminder</heading> > <body>Don't forget me this weekend!</body> > </note>
Changed the title to make it more clear what the found problem actually was
This also occurs on Fedora 40 with gzip-1.13-1.fc40.x86_64 so moved bug to Fedora 40
This still occurs on Fedora 41 (beta) which is gzip package gzip-1.13-2.fc41.x86_64 so this is now moved to Fedora 41
Still occurs on Fedora 42, tested with gzip-1.13-3.fc42.x86_64
Hello, seems to work on my system (f37), are you still able to reproduce this? Installed Packages Name : gzip Version : 1.12 Release : 2.fc37 Architecture : x86_64 Size : 381 k Source : gzip-1.12-2.fc37.src.rpm [jamartis@jamartisT480s tmp]$ cat foo.xml <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note> [jamartis@jamartisT480s tmp]$ gzip foo.xml [jamartis@jamartisT480s tmp]$ zless foo.xml.gz <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note> ================================================================ But did you remember to set LESSSECURE=1 ?? Your sample code didn't show you setting LESSSECURE to 1, I suspect this bug is nearly never seen because so few people set the LESSSECURE flag. I do that to make sure less doesn't accidentally change important code files. The bug only happens if you export LESSECURE=1 and then try to use zless
Just to be clearer, this is the problem as I still see on Fedora 42/gzip package gzip-1.13-3.fc42.x86_64 $ unset LESSSECURE $ echo $LESSSECURE (prove no LESSSECURE is set) $ dmesg | tail | gzip -c - > dmesg.gz (make a short test gzip file) $ gzip -tv dmesg.gz dmesg.gz: OK $ file dmesg.gz dmesg.gz: gzip compressed data, from Unix, original size modulo 2^32 961 (confirm file is gzip file) $ zless dmesg.gz [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 11 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring vcn_dec uses VM inv eng 0 on hub 8 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 1 on hub 8 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 4 on hub 8 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 8 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes (zless works without any LESSSECURE) $ export LESSSECURE $ zless dmesg.gz [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 11 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring vcn_dec uses VM inv eng 0 on hub 8 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 1 on hub 8 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 4 on hub 8 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 8 [Mon Sep 1 13:33:08 2025] amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes (zless works with empty LESSSECURE of no value) $ export LESSSECURE=1 $ zless dmesg.gz "dmesg.gz" may be a binary file. See it anyway? (fails if LESSSECURE is enabled)
> (zless works with empty LESSSECURE of no value) > $ export LESSSECURE Sorry that should have been: > (zless works with empty LESSSECURE of no value) > $ export LESSSECURE="" because "export LESSSECURE" does nothing all at to the environment
still occurs on Fedora 43 so bumping version to 43