Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 236465

Summary: non-root console use less hangs due to
Product: [Fedora] Fedora Reporter: Tom Laudeman <tom>
Component: bashAssignee: Tomas Janousek <tjanouse>
Status: CLOSED NOTABUG QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: rrakus, varekova
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-21 11:49:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Tom Laudeman 2007-04-14 16:24:33 UTC
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:


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

Version-Release number of selected component (if applicable):

How reproducible:

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 16:26:36 UTC
unset LESSOPEN also clears up the problem. It appears that /usr/bin/
is at the core of the problem.

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

Comment 3 Ivana Varekova 2007-04-17 10:31:03 UTC
I can't reproduce your problem - which terminal do you use please?

Comment 4 Tom Laudeman 2007-04-18 12:55:34 UTC
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 14:26:49 UTC
Thanks for information - I have reproduced your problem. But it seems to be bash
less uses command 
"/bin/bash -c /usr/bin/\ /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. 

Comment 6 Tomas Janousek 2007-10-30 16:44:11 UTC
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 11:49:54 UTC
I think it's not a bug -> closed NOTABUG