Bug 236465 - non-root console use less hangs due to lesspipe.sh
non-root console use less hangs due to lesspipe.sh
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Janousek
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-14 12:24 EDT by Tom Laudeman
Modified: 2008-03-21 07:49 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-21 07:49:54 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 Tom Laudeman 2007-04-14 12:24:33 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
says this:

read(4,

When everything is working, that line is read(3,

Version-Release number of selected component (if applicable):
less-394-5.fc6

How reproducible:
Always

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)
  
Actual results:
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.

Expected results:
less would work normally

Additional info:
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"
Comment 1 Tom Laudeman 2007-04-14 12:26:36 EDT
unset LESSOPEN also clears up the problem. It appears that /usr/bin/lesspipe.sh
is at the core of the problem.

Comment 2 Tom Laudeman 2007-04-14 13:02:42 EDT
Changing TERM to vt100 or ansi also makes less work, but creates other problems.
TERM=ansi
TERM=vt100

Comment 3 Ivana Varekova 2007-04-17 06:31:03 EDT
I can't reproduce your problem - which terminal do you use please?
Comment 4 Tom Laudeman 2007-04-18 08:55:34 EDT
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

export BASH_ENV=$HOME/.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).

To reproduce:

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.
export BASH_ENV=$HOME/.bashrc

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.


More info:
At runlevel 5 in the KDE konsole, the problem does not occur.
Comment 5 Ivana Varekova 2007-04-23 10:26:49 EDT
Thanks for information - I have reproduced your problem. But it seems to be bash
problem.
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.
command 
"/bin/bash"
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. 
Comment 6 Tomas Janousek 2007-10-30 12:44:11 EDT
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/*.
Comment 7 Roman Rakus 2008-03-21 07:49:54 EDT
I think it's not a bug -> closed NOTABUG

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