Bug 127492 - man pages all show up blank when bash's noclobber is on
man pages all show up blank when bash's noclobber is on
Product: Fedora
Classification: Fedora
Component: groff (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
: EasyFix
: 144053 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-07-08 18:09 EDT by Ry4an Brase
Modified: 2013-07-02 19:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-06 14:38:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ry4an Brase 2004-07-08 18:09:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
When use the man command less is invoked but receives no data on
standard input from which to display.  I tracked the problem down to
the nroff invocation.  When a man page is displayed the processing
chain invocation looks like this:

(cd /usr/share/man && (echo \".pl 1100i\"; /usr/bin/gunzip -c
\'/usr/share/man/man1/bash.1.gz\'; echo \".\\\\\\\"\"; echo \".pl
\\n(nlu+10\") | /usr/bin/gtbl | /usr/bin/nroff -c --legacy ISO-8859-1
-mandoc 2>/dev/null | /usr/bin/less -is

The /usr/bin/gtbl step is correctly producing output.  However, the
/usr/bin/nroff invocation is dying.  Running it manually (and without
the standard error redirected to /dev/null), I can see the error looks
like this:

$ /usr/bin/nroff  -c --legacy ISO-8859-1 -mandoc
/usr/bin/nroff: line 50: /tmp/man.bK4961: cannot overwrite existing file

Opening up the /usr/bin/nroff script the relevant portion looks like
this (with line numbers added):

    47  TMPFILE=$(mktemp /tmp/man.XXXXXX)
    48  trap "rm -f $TMPFILE" 0 1 2 3 15
    50  cat ${1+"$@"} > ${TMPFILE}

I chanced the (previously blank) line 49) to a 'ls -l $TMPFILE' and
it's clear that the 'rm' on line 48 is failing silently.  That causes
the redirection on line 50 to fail on systems (such as mine) where the
bash option 'noclobber' is (sanely) set to 'on'.

There are a few easy fixes/workarounds.  One would be to find out why
the 'rm' fails -- I've been unable to figure it out myself.  The
easier fix is to eliminate the rm in line 48 altogether and just
change line 50 to:

cat ${1+"$@"} >> ${TMPFILE}

Using append rather than overwrite for the redirect safely relies on
the file created by mktemp to be empty.

Version-Release number of selected component (if applicable):
groff-1.18.1-34 with man-1.5m2-6

How reproducible:

Steps to Reproduce:
1. put 'set -C' in your /etc/bashrc
2. start a new shell
3. type 'man man'

Actual Results:  an empty less shows up

Expected Results:  the less should have contained the text of the man
man page

Additional info:

I know this is a bug in nroff (or maybe even in trap), but I figured
putting it in 'man' makes the most sense.
Comment 1 Eido Inoue 2004-11-05 14:44:16 EST
groff should be the proper component for this
Comment 2 John Weldon 2004-11-18 11:48:37 EST
This simple patch makes the most sense to me... I've had to change
this every release of fedora core: (This is for the Fedora Core 3
version of nroff /usr/bin/nroff)

< cat ${1+"$@"} > ${TMPFILE}
> cat ${1+"$@"} >| ${TMPFILE}
Comment 3 Matthew Miller 2005-04-26 11:10:34 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 4 Ry4an Brase 2005-04-26 11:21:38 EDT
also happens in FC3 -- very frustrating and easily fixed once found.
Comment 5 Matthew Miller 2005-04-26 11:47:41 EDT
FWIW -- the line

   trap "rm -f $TMPFILE" 0 1 2 3 15

is working as expected. It doesn't cause "rm -f $TMPFILE" to be executed
automatically, but rather if the script catches one of the listed signals (0 =
script exit, 1 = sighup, 2 = sigint, 3 = sigquit, 15 = sigterm). Basically, it's
the cleanup. So that's what's going on there.

However, the basic issue has nothing to do with that line. I think John Weldon's
trivial suggestion in comment #2 is the best fix -- just change > to >|.

Also, I just checked and the problem is also still there in the current
development RPM.
Comment 6 Jindrich Novy 2005-04-28 08:39:03 EDT
*** Bug 144053 has been marked as a duplicate of this bug. ***
Comment 7 Paramjit Oberoi 2005-09-26 23:48:20 EDT
This is still happening in FC4.
Comment 8 Jindrich Novy 2006-01-06 14:38:51 EST
Fixed since

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