Dear Mailing List and esp. Maintainers,
as found out via investigation[1] triggered by the same bug in a different implementation
of `zless`, gzip's `zless` has a bug:
When you (as is generally kind of not a bad idea to do) have exported LESSSECURE=1, `less`
will refuse to work with programs passed through
LESSOPEN='|…'
as piped-through processes. Now, that's the central working principle of
`zless` [2]:
|LESSOPEN="|$check_exit_status${use_input_pipe_on_stdin}gzip -cdfq -- %s"|
Thus, in environments with reasonable security settings, `less` will not run `gzip`, hence
will tell the user that "input is a binary file" and try to display the compressed
original file.
I'd blame `less` a tiny bit for not even informing the user about things being ignored,
but then again, it's how its always worked.
So, to the unsuspecting user
export LESSSECURE=1 # often done in /etc/profile or similar place
echo "Hello World" > helloworld.txt
gzip helloworld.txt
zless helloworld.txt.gz
will result in
"helloworld.txt.gz" may be a binary file. See it anyway? y
^_<8B>^H^H<8A><EE>;d^@^Chelloworld.txt^@<CB>H<CD><C9><C9><C9>W<E0>^B^@R[|<DB>^H^@^@^@
helloworld.txt.gz (END)
Best regards,
Marcus
[1]
https://unix.stackexchange.com/questions/743049/issue-viewing-compressed-file-with-zless-but-not-with-zmore-or-gunzip-c#comment1412495_743050+
[2] https://git.savannah.gnu.org/cgit/gzip.git/tree/zless.in#n77
