Hide Forgot
On a system upgraded from 6.1 to 6.1.92, `less` fails to work. when I use it, ie: less somefilename I get for output: ESC]2;swoop.support.redhat.com^G For some reason, on plain text files it seems to be wanting to try to run it though "lessopen.sh" and breaking in the process. When looking at files that "lessopen.sh" should be able to read, I get the intented output, but the above string is prepended to everything. I suspect that whatever less is doing to determine if the file should be open with the lessopen script is broken. setting: export LESSOPEN= makes it work normally as suspected.
There was a bug in less a while ago (lesspipe.sh instead of |lesspipe.sh). It's fixed in dist-6.2, probably also in 6.2beta3.
It doesnt seem to be fixed in beta3. This is with less-346-1, ie: [alikins@swoop ldap_test]$ rpm -q less less-346-1 [alikins@swoop ldap_test]$ rpm -q --changelog less * Tue Jan 25 2000 Bernhard Rosenkraenzer <bero@redhat.com> - Update to v346 - Update download URL - use the configure marcro - strip binary - fix up lesspipe stuff (Bug #8750 and a couple of non-reported bugs) This appears to be the latest version of less available. I should mention this was on an upgrade, as it doesnt seem many others have encountered this, I suspect thsi may be related. Fwiw: [alikins@swoop alikins]$ echo $LESSOPEN |/usr/bin/lesspipe.sh %s
This happened after the above fixed you mentioned, and is still seen even in the latest versions. This happened on both machines I upgraded, so I suspect its somehow related. Same failure mode after another round of updates.
Okay, narrowed this down a bit more. It seems to somehow be related to my .bashrc. In particular, the lines: function xt(){ echo -ne '\033]2;'"$*"'\007'; } xt $HOSTNAME (to set the the xterm title to the host I'm currently on, though something appears to be doing that also now..) Removing those lines makes `less` open as expected. Still seems a bit odd to me.
aiee. Its /etc/bashrc settings colliding with my own and somehow breaking less. Whatever. At least I know why it was only happening to me now.
Ok, this is interesting... Seems the bash instance opened by less executes .bashrc for some reason, so you see everything you echo in bashrc. Does changing the #!/bin/sh in lessopen.sh to #!/bin/bash -norc change anything? Does encapsulating the xt stuff in if [ "$PS1" ]; then [ xt stuff ] fi help? That way, it should be executed only for interactive shells where it makes sense.
Hi, I have the same problem on 6.2. I use tcsh throughout the system and in /etc/csh.cshrc, I have echo " " fortune echo " " And so, whenever you "less <filename>" you see a fortune cookie instead :) Cute, but annoying! you have to "cat <filename> | less". Alternatively, you can "unsetenv LESSOPEN" and it works too, because unsetting the ENV will stop less from using lesspipe.sh I also tried to change lesspipe.sh from #!/bin/sh to #!/bin/sh -norc #!/bin/bash -norc #!/bin/bash -norc -noprofile #!/bin/tcsh -f But didn't get a chance to change the entire script to tcsh style.. But the thing that really gets me is if lesspipe.sh is using sh/bash, why is the results of /etc/csh.cshrc being run? csh.cshrc is only run by csh/tcsh, while bash uses /etc/profile right? Sounds like less itself has a problem when it spawns a shell to execute LESSOPEN/lesspipe.sh... sigh.. anyone got a proper fix for this problem?
I have solved the problem by commenting out all the lines in the two files /etc/profile.d/less.csh /etc/profile.d/less.sh This will avoid setting "LESSOPEN". Restart your session and less wil work as usual.
I found I can fix less (I use tcsh) by changing one line in lesspipe.sh. I think there is a real coding bug here - the case statement doesn't do anything if the file doesn't match any of the known filetypes, ie. is a simple txt file. I change: esac to esac || cat $1; and less seems to work now for both binaries and simple text. If case didn't match a known filetype then it returns 0 and cat is run on the raw file.
Quick followup, The above fix stopped working for me as soon as I posted it. (Grrr) However adding this case: *) cat $1; to the end of the list accomplishes the same thing. Note that the problem with executing peoples' .bashrc and .tcshrc is still there.
*** Bug 10708 has been marked as a duplicate of this bug. ***
*** Bug 10397 has been marked as a duplicate of this bug. ***
Finally found out what's causing this; fixed in 358-3.