Bug 9443 - less fails because of "lessopen.sh"
less fails because of "lessopen.sh"
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: less (Show other bugs)
6.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
:
: 10397 10708 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-14 16:57 EST by Adrian Likins
Modified: 2008-05-01 11:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-26 14:42:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adrian Likins 2000-02-14 16:57:46 EST
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.
Comment 1 Bernhard Rosenkraenzer 2000-02-14 17:01:59 EST
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.
Comment 2 Adrian Likins 2000-02-14 18:24:59 EST
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
Comment 3 Adrian Likins 2000-02-18 20:08:59 EST
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.
Comment 4 Adrian Likins 2000-02-18 20:20:59 EST
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.
Comment 5 Adrian Likins 2000-02-18 20:23:59 EST
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.
Comment 6 Adrian Likins 2000-02-18 20:25:59 EST
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.
Comment 7 Bernhard Rosenkraenzer 2000-02-19 03:49:59 EST
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.
Comment 8 Anonymous 2000-04-12 21:30:59 EDT
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?
Comment 9 Luca Bonomi 2000-04-18 10:07:59 EDT
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.
Comment 10 corth 2000-06-27 10:31:29 EDT
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.
Comment 11 corth 2000-06-27 13:39:55 EDT
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.
Comment 12 Bernhard Rosenkraenzer 2000-07-26 14:41:54 EDT
*** Bug 10708 has been marked as a duplicate of this bug. ***
Comment 13 Bernhard Rosenkraenzer 2000-07-26 14:42:21 EDT
*** Bug 10397 has been marked as a duplicate of this bug. ***
Comment 14 Bernhard Rosenkraenzer 2000-07-26 14:44:29 EDT
Finally found out what's causing this; fixed in 358-3.

Note You need to log in before you can comment on or make changes to this bug.