$ less foo.bin This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. foo.bin lines 1-3/3 (END) WTF at this point. My file contains something entirely different. From /usr/bin/lesspipe.sh: *.bin|*.cue|*.raw) # not all .bin/.raw files are cd images, so fall back to hexdump cd-info --no-header --no-device-info "$1" || lesspipe_file "$1" ;; This is very bad idea. In fact, most .bin files aren't CD images. Mine was just text that I wanted to view with less. less is a text viewer. If I wanted to view a .bin file as CD image, I'd use cd-info directly, not something that's supposed to be a text viewer. I have a similar feeling for many other things I find in lesspipe.sh. While many of them are binary formats by nature and cannot be sensibly viewed as text, less on things like .ps, .rtf, manpages should display their raw contents. Reproducible: Always Steps to Reproduce: 1. less nonexistentfile.bin 2. Stare in bewilderment at the message. 3. less existentfile.bin 4. Stare in even more bewilderment at the message. Actual Results: I view junk. Expected Results: I view contents of file.
Sounds like an upstream decision, please complain to them
lesspipe.sh comes from /usr/portage/sys-apps/less/files, this behavior is introduced by gentoo. Reopening.
IMHO also the behaviour for the following should be reconsidered: .ps (it is often useful to view PostScript files as sources) .doc (in a Unix context this is most likely to be plain text)
it is impossible to handle everyone. if you dont like lesspipe guessing at stuff, then dont use it (dont use LESSOPEN). cd-info seems to work fine for me ignoring non-cd .bin images
Apparently, the --no-header from dev-libs/libcdio-0.82 does not prevent this three-line copying & disclaimer header, only the actual copyright lines. Which can be really confusing in front of an arbitrary bin file. In fact, having the --no-header flag makes things worse, as it suppresses the information about which binary generated that message. So I suggest removing that particular rule. If you ABSOLUTELY want to keep it, please run it twice, once redirecting its output to /dev/null to check whether it is a CD image, and once again with its output intact only if the first run succeeded. And drop the --no-header flag, so we know where the message belongs to. Looking more closely at what cd-info says: $ cd-info foo.bin cd-info version 0.82 x86_64-pc-linux-gnu Copyright (c) 2003, 2004, 2005, 2007, 2008 R. Bernstein This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. **ERROR: source name foo.cue is not recognized as a CUE file So it appears that even when run on a *.bin file, it's the *.cue file that cd-info is actually using. You probably might as well restrict the rule to cue files only, or at least require that there is a cue file accompanying the bin file before trying that rule. As to why the binary file won't display, I cannot reproduce that. For me, those three lines appear in front of a hexdump. Perhaps you don't have sys-apps/util-linux installed? If that's the reason, perhaps lessopen should ensure that a given binary exists before attempting to use it. To see what commands are executed, and what error messages they might print, please use "LESSDEBUG=1 lesspipe <FILE>". (In reply to comment #0) > I have a similar feeling for many other things I find in lesspipe.sh. While > many of them are binary formats by nature and cannot be sensibly viewed as > text, less on things like .ps, .rtf, manpages should display their raw > contents. The more lesspipe tries to be clever, the more often I find myself using the -L switch to suppress this cleverness. So I generally agree, although I must confess that I consider the implicit rendering of manpages very convenient. The same might be true for a lot of other rules, so instead of dropping them altogether, perhaps we should export a default list of LESSIGNORE suffixes as part of the default environment, giving users the chance to taylor that list to their own needs. "export LESSIGNORE='bin raw ps'" certainly seems a good idea for myself just now.
the output issue has already been posted upstream: https://savannah.gnu.org/bugs/?29307 guess i need to attach a patch to it. or if you really want, feel free to do this for me :P. i don't think checking for programs before attempting to execute them would make any difference. it certainly would make the code unnecessarily complicated. i haven't experienced any misbehavior with default lesspipe, so i'm not inclined to export a default ignore list ...
(In reply to comment #6) > the output issue has already been posted upstream: > https://savannah.gnu.org/bugs/?29307 > guess i need to attach a patch to it. or if you really want, feel free to do > this for me :P. Patch sent upstream. :-) I'm not sure I like the idea of waiting for it to reach Gentoo, though. How about the other suggestions, particularly associating only *.cue with cd-info, or as an alternative checking whether *.cue exists. Will you consider those? Or is it your opinion that the cd-info invocation shouldn't hurt (once the header is fixed), so there is no need to make an effort avoiding unsuccessful calls?
this should do it: http://sources.gentoo.org/sys-apps/less/files/lesspipe.sh?r1=1.45&r2=1.46
