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 49 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: Always 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.
groff should be the proper component for this
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) 50c50 < cat ${1+"$@"} > ${TMPFILE} --- > cat ${1+"$@"} >| ${TMPFILE}
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.
also happens in FC3 -- very frustrating and easily fixed once found.
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.
*** Bug 144053 has been marked as a duplicate of this bug. ***
This is still happening in FC4.
Fixed since 1.18.1.1-7.