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.

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.