[I'm posting this to Cooker also because I believe that implicitly doing "source
.${SHELL}rc" when invoking "less" is a very dangerous timebomb... IMHO]
Al Andersen wrote:
>
> I had the same problem with my 7.2 system. The way I resolved it was to edit
> /etc/profile and comment out:
>
> #if [ -x /usr/bin/lesspipe.sh ];then
> # export LESSOPEN="|/usr/bin/lesspipe.sh %s"
> #fi
>
> Your mileage may vary :)
MMDV... unfortunately, this kills the useful stuff within lesspipe.sh, like
automatic handling of different file types.
More digging... the problem is the way 'less' pipes <filename> to $LESSOPEN
when the latter starts with "|" (doh! :^)...
Tried a lot of different things; hopefully I got the results straight...
export LESSOPEN="| /bin/sh --norc /usr/bin/lesspipe.sh %s"
^^^^^^^^^^^^^^
starts a shell which for some reason ignores "--norc" whether specified here or
on the #!/bin/sh line within lesspipe.sh...
Without the pipe symbol, less invokes "$SHELL -c $LESSOPEN" which makes it
impossible to use --norc here.
export SHELL=/bin/csh
Changing the shell avoids .bashrc; but lesspipe.sh still invokes /bin/sh. To
change this to '#!/bin/csh' requires rewriting lesspipe.sh... Adding --norc to
the shebang line does nothing. Not sure if .cshrc would have the same
problem...
export LESSOPEN="| /bin/cat %s"
This still invokes .bashrc...
export LESSOPEN="/bin/sh --norc < /usr/bin/lesspipe.sh %s"
export LESSOPEN="|/bin/sh < /usr/bin/lesspipe.sh %s"
export LESSOPEN="|/bin/sh --norc < /usr/bin/lesspipe.sh %s"
These kinda work; but on "q[uit]", "less foo.html" gives:
foo.html: line 1: syntax error near unexpected token `<html>'
foo.html: line 1: `<html>'
starts a shell which for some reason will not accept "--norc" either on the
#!/bin/sh line, or within LESSOPEN...
export LESSOPEN="/bin/sh < /usr/bin/lesspipe.sh %s"
This variation also kinda works; but gives:
bin/sh: Command not found.
The bottom line is that anything in .bashrc will execute because running "less"
results in implicitly doing a "source .bashrc", not to mention that anything
.bashrc sends to STDOUT is injected into the pipe... On the whole, this seems
poorly thought out... though my C skills are quite rusty from lack of use and
old age... :}
However, creating lesspipe.py and using:
export LESSOPEN="| /usr/bin/lesspipe.py %s"
avoids the shell timebombs... here's a Python version (based on LM7.2; 8.0's
lesspipe.sh is much different):
-----------------------------------
#!/usr/bin/env python
import os, sys, re
FILE = sys.argv[1]
TYPE = os.popen("file -L %s | cut -d' ' -f2-" % FILE ).read()
if re.match('gzip', TYPE): CMD='gzip -d -c -q'
elif re.match('compress\'d\ data', TYPE): CMD='uncompress -c'
elif re.match('GNU\ tar', TYPE): CMD='tar -tvf'
elif re.match('Zip', TYPE): CMD='unzip -c -qq'
elif re.match('Zoo', TYPE): CMD='zoo xqp'
elif re.match('ARC', TYPE): CMD='arc pn'
elif re.match('LHa', TYPE): CMD='lha p'
elif re.match('RAR', TYPE): CMD='unrar p'
elif re.match('RPM', TYPE): CMD='rpm -qpil'
#elif re.match('ARJ', TYPE): unset CMD
elif re.match('ELF', TYPE): CMD='strings'
elif re.match('Linux/i386', TYPE): CMD='strings'
elif re.match('MS-DOS\ executable', TYPE): CMD='strings'
elif re.match('MS-Windows', TYPE): CMD='strings'
elif re.match('Win95\ executable', TYPE): CMD='strings'
elif re.match('bzip2\ compressed', TYPE): CMD='bunzip2 -d -c'
elif re.match('bzip\ compressed', TYPE): CMD='bunzip -d -c'
elif re.search(".bz$", sys.argv[1]): CMD='bunzip -d -c'
elif re.search(".bz2$", sys.argv[1]): CMD='bunzip2 -d -c'
else: CMD=None
if CMD:
print os.popen("%s %s 2> /dev/null" % ( CMD, FILE )).read()
-----------------------------------
Note: no logic was corrected in this simple (7.2) re-write...
HTH,
Pierre
> -Al
>
> On Friday 22 June 2001 13:51, Pierre Fortin wrote:
> > Hi,
> >
> > Before I go digging into the sources, does anyone know the logic behind
> > "less" being impacted by the contents of .bashrc...?
> >
> > If I add 'echo "foobar"' to my .bashrc, any attempt to "less <file>" gives
> > only "foobar" as output instead of the expected contents of <file>.
> >
> > The env. vars are:
> > $ for e in ${!LESS*}; do echo $e ${!e};done
> > LESS -MM
> > LESSKEY /etc/.less #doesn't exist
> > LESSOPEN |/usr/bin/lesspipe.sh %s #nothing weird here
> >
> > I've strace'd it and see this line:
> > pipe([5, 6]) = 0
> > (the numbers are not always 5 & 6) which is probably from the LESSOPEN
> > pipe...
> >
> > I don't see less opening .bashrc or invoking it; but less somehow gets
> > output from .bashrc... What I can't determine yet is whether this "output"
> > is from ..bashrc executing anew when less is run (most likely -- see
> > below), or from a stale buffer somewhere... I just can't imagine a
> > scenario where less needs to either access .bashrc or get data from a
> > non-user-specified pipe... could this be a potential security hole...?
> >
> > The problem is even more confusing if I add some code to .bashrc; it gets
> > executed when I invoke less, instead of displaying the requested file...
> > this would seem to indicate .bashrc is executed when less is invoked...
> >
> > This happens on both my LM7.2 machines; but not on the 8.0 one, though the
> > latter has the same env. vars and the same pipe in strace output... but,
> > the default .bashrc is different...
> >
> > Puzzling.
> >
> > Pierre
--
Support Linux development: http://www.linux-mandrake.com/donations/
Last reboot reason: 06/22/01: added 512M memory