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 gzip).

I think it would be better if upstream 'less' would distribute a lesspipe.sh and perhaps even install it by default.

Best regards,

Zutils-bug mailing list

Reply via email to