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 - non-root console use less hangs due to lesspipe.sh
Summary: non-root console use less hangs due to lesspipe.sh
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 6
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Janousek
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-14 16:24 UTC by Tom Laudeman
Modified: 2008-03-21 11:49 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-03-21 11:49:54 UTC


Attachments (Terms of Use)

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:

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 16:26:36 UTC
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 17:02:42 UTC
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 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
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 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


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