This problem still exists in etch and unstable as of 2008/10/17.
It is a problem with less's LESSOPEN environment variable feature.
bzless works around the problem by bypassing the LESSOPEN functionality
altogether. So this is definitely a bug in less, and is present on mac
os x and probably most if not all other operating systems/distributions,
as well in upstream less 418 and less 424 BETA (latest upstream beta,
dated 2008/06/23).
A little testing shows that less is receiving '-' as the filename, which
is as it should be, so the problem seems to be in less's filename.c --
on line 831 of less v418 with debian patches applied in open_altfile()
-- where we see the following:
if (strcmp(filename, "-") == 0)
return (NULL);
The attached patch simply removes the offending return. As far as I can
tell, this does not break anything, considering a test suite (ran by
hand) of:
cat foo.gz | zless
zless foo.gz
cat foo | less
less foo
cat foo.gz | zless -J
zless -J foo.gz
cat foo | less -J
less -J foo
That said, I rarely use zless options, and therefore cannot verify that
all possible options to less work with this patch applied. If they do,
and if this is applied upstream, it would be nice to use the same,
simple LESSOPEN/exec method used in zless instead of the complicated and
imperfect method used in bzless (which doesn't utilize LESSOPEN and
therefore doesn't know which file it's in, among other things, as
pointed out earlier in this thread)
Cheers,
Brian Szymanski
[EMAIL PROTECTED]
--- less-418.DIST/filename.c 2007-12-10 11:35:52.000000000 -0500
+++ less-418/filename.c 2008-10-17 22:20:16.000000000 -0400
@@ -828,8 +828,10 @@
ch_ungetchar(-1);
if ((lessopen = lgetenv("LESSOPEN")) == NULL)
return (NULL);
- if (strcmp(filename, "-") == 0)
- return (NULL);
+// HACK: these two lines break the form cat foo.gz | zless, etc.
+// but disabling them might break some other functionality...
+// if (strcmp(filename, "-") == 0)
+// return (NULL);
if (*lessopen == '|')
{
/*
