I think the rules in lesspipe.sh that run groff on various files are more annoying than they are helpful. I always run into problems trying to look at /var/log files (such as syslog.0, or mail.info.1.gz) and also trying to look at screenlog files (which are named for the window number, such as screenlog.2) -- the default lesspipe setup completely mangles these files. I'd prefer to see the groff rules completely removed, but failing that, I'd like to see them rewritten so that they don't run groff on an ASCII file (only if the file is identified as "ASCII troff").
Created attachment 10239 [details, diff] lesspipe.sh improvement If the Powers That Be don't wish to remove the *.[1-9] and *.[1-9].gz cases from the lesspipe.sh file, this patch contains changes that makes it only work if the file is identified as being a "troff" file. Fixes include changing the *.[1-9] rule to look at the right column (3, not 2) for the string "troff", adding 2>/dev/null to the second groff command, eliminating the checks for "ASCII" (so that non-troff data doesn't get mangled), and (!) making the *.[1-9].gz case fall back to just unzipping the data if it doesn't turn out to be troff data (the old lesspipe.sh script would pass through the binary data unchanged if it failed the troff/ASCII check, which was also annoying).
This bug still exists (and I find it annoying, also). I ran into it the exact same way that Wayne did (trying to use less on old log files). I hope some additional attention will get it fixed soon.
Created attachment 32069 [details, diff] Patch, detect troff correctly, decompress if not troff This patch includes the changes made by the previous patch. And it also corrects the detection of troff-files.
This "lesspipe.sh improvement" patch fixes some of the problems, I can now use less for /var/log/messages.1.gz But the man page viewing is still broken: niels@lisa man1 $ zcat zipinfo.1.gz | file - /dev/stdin: troff or preprocessor input text niels@lisa man1 $ zcat znew.1.gz | file - /dev/stdin: ASCII troff or preprocessor input text znew.1.gz will be piped through groff but zipinfo.1.gz won't. That is because gzip -dc $1 2>/dev/null|file -|tr -s ' '|cut -d ' ' -f3 will output "or" for zipinfo.1.gz, and not "troff". I have made a new patch that also includes correct detection of troff.
Created attachment 32070 [details, diff] Faster patch, detect troff correctly, decompress if not troff This patch replaces all earlier posted patches. It fixes troff recognition and decompresses *[0-9].gz files if they are not troff files. The only difference to 32069 is that this patch reuses file output. So it doesn't decompress the files 2 times to cut out 2 different words from the file output.
Fixed in less-382-r1, thanks!
Created attachment 37799 [details, diff] Make lesspipe.sh-r2 decompress a *.[1-9].gz file if it is not a troff file If I were alowed I would have reopened this bug. lesspipe.sh-r2 contains this action for *.[1-9].gz files: *.[1-9].gz | *.n.gz | *.man.gz) [[ $(gzip -dc "$F" 2>/dev/null | file -) == *troff* ]] && \ gzip -dc "$F" 2>/dev/null | groff -S -s -p -t -e -Tascii -mandoc ;; Since /var/log/messages.1.gz is not a troff file lesspipe.sh-r2 won't do anything to it, so less will show the compressed file directly. Instead lesspipe.sh should gunzip the file if it is not a troff file, which could be accomplished by changing the above to this: *.[1-9].gz | *.n.gz | *.man.gz) [[ $(gzip -dc "$F" 2>/dev/null | file -) == *troff* ]] && \ gzip -dc "$F" 2>/dev/null | groff -S -s -p -t -e -Tascii -mandoc || gzip -dc "$F" 2>/dev/null ;; And that is what this patch does.
Adding agriffis@gentoo.org as CC. I'm afraid there is still a problem in lesspipe.sh-r2 where /var/log/messages.1.gz is not decompressed.
Still doesn't work. Can someone reopen this?
reopening at user request
*** Bug 63434 has been marked as a duplicate of this bug. ***
fixed in cvs, thanks
Apparently the fix has still not made it into the portage tree :( Would someone please take a look at that?
