Red Hat Bugzilla – Bug 236465
non-root console use less hangs due to lesspipe.sh
Last modified: 2008-03-21 07:49:54 EDT
Description of problem:
runlevel 3, login as non-root user, less a text file. Less hangs (no output) and
requires control-c, after which it works fine. The tail of strace less tmp.txt
When everything is working, that line is read(3,
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. runlevel 3
2. login as non-root user (it works fine for root)
3. less tmp.txt (just less any normal text file)
Cursor goes to the next line. keyboard is unresponsive to all normal less
commands. Use control-c to get out of this hung state. After control-c less
appears to work normally.
less would work normally
strace less tmp.txt give a last line of "read(4," when the problem occurs.
Control-c at this point leaves the tty is a bad state. The "bad" state of the
tty is cleared by the usual "stty sane control-j"
unset LESSOPEN also clears up the problem. It appears that /usr/bin/lesspipe.sh
is at the core of the problem.
Changing TERM to vt100 or ansi also makes less work, but creates other problems.
I can't reproduce your problem - which terminal do you use please?
I did more research on this problem, and I have reproduced it on a second computer.
The problem is related to BASH_ENV being in .bashrc
Also, ~/.bash_profile must source .bashrc
You must be on the "console", that is, run level 3, sitting at the keyboard and
monitor of the computer (ssh into the computer does not have the problem).
1) You must have .bashrc and .bash_profile and .bash_profile
2) .bash_profile must source .bashrc
3) add BASH_ENV to your .bashrc, and the value must be your .bashrc file.
4) At a bash prompt, launch a new shell bash. The new shell immediately hangs
waiting for input. You will not get a prompt. Enter a control-C. Now you have a
working second shell.
5) I have reproduced this on a second computer. Both are Dell. Both are running
FC6. However, they are very different machines. The first is a consumer grade
home machine. The second is a dual Xeon tower server with an "nVidia Corporation
NV34GL [Quadro FX 500/600 PCI]" video card.
At runlevel 5 in the KDE konsole, the problem does not occur.
Thanks for information - I have reproduced your problem. But it seems to be bash
less uses command
"/bin/bash -c /usr/bin/lesspipe.sh\ /tmp/txt"
to convert the standart formats of files.
This command is broken - it freeze - and the user have to press Ctrl-C to kill
it -> what is just what less needs to skip this pfase and display the result.
has just the same behavior on my test system.
So I'm reassigning this bug to bash.
I can reproduce this bug so if there is any problem with the reproduction of it
I can lend my test system.
This happens because .bashrc sources /etc/bashrc, which sources
/etc/profile.d/*.sh one of which calls /bin/unicode_start, which is a shell
script so bash starts, looks at BASH_ENV, sources .bashrc, which sources
/etc/bashrc, ... and recurses forever.
I don't think this is a bug. You shouln't set BASH_ENV to anything that sources
/etc/bashrc and/or /etc/profile and/or /etc/profile.d/*.
I think it's not a bug -> closed NOTABUG