Daniel Baumann wrote:
while I agree that zless should preferably be removed, the reality is
that it is around and that people are acustom to it. This is "backed" by
the fact that there has nothing happened at gzip wrt/ that in all these
Nothing has happened at gzip just because features tend to never get
removed, don't mind how inferior or obsolete they are.
I think it would be a bad idea to add a zless to zutils because (among
other things) the functionality that users expect from lesspipe is much
wider than what is adequate for zutils. Just compare what less+lesspipe
do compared with what zless does (with no lesspipe installed):
'less file.tar.gz' == 'tar tzvvf file.tar.gz | less'
'zless file.tar.gz' == 'gzip -cd file.tar.gz | less'
'less file.tar' == 'tar tzvvf file.tar | less'
'zless file.tar' == 'cat file.tar | less'
'less file.zip' == 'unzip -l file.zip | less'
'zless file.zip' == 'gzip -cd file.zip | less'
'less file.rpm' == 'rpm -qpvl file.rpm | less'
'zless file.rpm' == 'gzip -cd file.rpm | less'
'less file.1.gz' == 'gzip -cd file.1.gz | nroff -S -mandoc - | less'
'zless file.1.gz' == 'gzip -cd file.1.gz | less'
zless may work in the case cited by Jesse Hathaway (less log.gz), but it
fails miserably in most other cases.
personally, I would welcome a zless from zutils. If there's no interest
from Antonio, we could also add a (although debian specific and thus
suboptimal) zless alias for lesspipe in the zutils package in debian.
Do you mean an alias for 'lesspipe "$1" | less'?
zless is meant to be called by the user, but lesspipe is not. lesspipe
does funny things if called for a non-compressed file, or with more than
one file argument.
I think this would create a conflict whith less. If LESSOPEN is set in
the environment, zless could override it. But if less uses /etc/lesskey,
the effect of zless is nullified (at least if zless is implemented as in
I think it would be better if upstream 'less' would distribute a
lesspipe.sh and perhaps even install it by default.
Zutils-bug mailing list