Description of problem: Normally when man pages are redirected to a file or piped, screen formatting codes (eg. ANSI escape sequences) are removed. However, in FC14, certain man pages leave behind ANSI code garbage mixed in with the pages, making them unreadable on line printers, dumb terminals, grep, etc. Example from a linux text console or konsole: ---- # man man | head -10 MAN(1) Manual pager utils MAN(1) 1mNAME0m <-- BAD man - an interface to the on-line reference manuals 1mSYNOPSIS0m <-- BAD 1mman 22m[1m-C 4m22mfile24m] [1m-d22m] [1m-D22m] <-- BAD ---- Version-Release number of selected component (if applicable): I'm not sure if the problem is with man, or one of the many other tools man depends on, eg. col(1). How reproducible: It is sometimes intermittent. I have noticed in konsole if I resize the konsole, to something small and redo the command, the problem will sometimes go away, giving different results. In konsole, TERM is set to 'xterm', in linux text console, Steps to Reproduce: 1. Login to linux console as root (eg. CTRL-ALT-F3, login: root) 2. run: man man | head -10 Actual results: See "1m" and "0m" sequences mixed in output, which appear to be the tail end of ANSI escape sequences, eg ESC[1m, ESC[0m, etc. Expected results: *No* "1m" and "0m" sequences mixed into output. Additional info: I think the commands 'man' ends up running (tbl,nroff..) are generating new and different ANSI escape sequences that 'col -b' does not understand, and therefore cannot strip. ('man col' shows col's limited subset, which does not include ESC[1m / ESC[0m highlighting sequences. These tools used to generate backspace overstrike sequences IIRC)
Forgot to mention in the above report: ..in linux text console, *TERM is set to "linux"*. The TERM settings are the defaults. Here is the output of 'printenv|sort' from a linux console, in case it helps: CCACHE_DIR=/var/cache/ccache CCACHE_UMASK=002 CVS_RSH=ssh G_BROKEN_FILENAMES=1 HISTCONTROL=ignoredups HISTSIZE=1000 HOME=/root HOSTNAME=ozark KDEDIRS=/usr KDE_IS_PRELINKED=1 LANG=en_US.UTF-8 LESSOPEN=|/usr/bin/lesspipe.sh %s LOGNAME=root LS_COLORS=[..unrelated info snipped..] MAIL=/var/spool/mail/root PATH=/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin PWD=/root QTDIR=/usr/lib64/qt-3.3 QTINC=/usr/lib64/qt-3.3/include QTLIB=/usr/lib64/qt-3.3/lib SHELL=/bin/bash SHLVL=1 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass TERM=linux USER=root _=/usr/bin/printenv XDG_SESSION_COOKIE=1823dcfe030b50379015bde00000000d-1293863891.991456-2018466980
This is man-db bug.
This works fine in Debian; man-db (upstream) sets GROFF_NO_SGR if stdout isn't a tty, which causes groff to omit these escape sequences. I don't see any relevant changes to Fedora's groff that would stop this working. I'll have to create a Fedora VM to investigate this.
I am unable to reproduce this in a fresh F14 virtual machine. Is it at all possible that you have the MAN_KEEP_FORMATTING environment variable set (you shouldn't normally)? Could you attach /etc/man_db.conf? Could you run 'man -d man 2>man.debug | head -10', confirm that you've reproduced this bug, and attach the resulting man.debug file?
I can not reproduce this bug myself, Greg could you attach here your /etc/man_db.conf configuration file and output of debug output of affected run?
I'm closing this bug because of insufficient data. Please if you can provide wanted info reopen this bug and paste info here.