Description of Problem: Watch this (long lines broken for display purposes): $ man colcrt | col -b COLCRT(1) System General Commands Manual COLCRT(1) NAME colcrt - filter nroff output for CRT previewing SYNOPSIS colcrt [-] [-2] [file ...] DESCRIPTION Colcrt provides virtual half-line and reverse line feed sequences for terminals without such capability, and on which overstriking is destruc Error executing formatting or display command. System command (cd /usr/share/man && (echo ".pl 11i"; /usr/bin/gunzip -c '/usr/share/man/man1/colcrt.1.gz') | /usr/bin/gtbl | /usr/bin/nroff -mandoc | less -n) exited with status 36096. No manual entry for colcrt Version-Release number of selected component (if applicable): util-linux-2.11f-17 and all other current updates for RH 7.2. How Reproducible: Just to be sure - the above is pasted from a gnome-terminal on X display. Sometimes an output from the pipe above will just stop in the middle of an expected display and no error shows up; and sometimes only "Error executing ..." part is visible. It seems to depend a bit, but not too much, for a manpage used in experiments.
I should mention that the system on which this happens was originally a 7.1 installation upgraded to 7.2 and to which all current updates were applied. At the moment I do not have handy 7.2 installed "on a clean slate".
Please try the packages at http://people.redhat.com/~sopwith/2.11n-1/ to see if they help at all. I can't reproduce the problem with that package installed...
This hits a minor snag like that: Forbidden You don't have permission to access /~sopwith/2.11n-1/ on this server. And ftp://people.redhat.com/sopwith/ does not seem to have a subdirectory like 2.11n-1. BTW - if I am running quoted shell command directly from a shell then nothing bad happens. So "funnies" are either in a wrapper or in communication (mixed up status handling for i/o through pipes?).
Erk, stupid httpd settings, I added an index.html that should get you what you need.
Ok, this helps; but we are running into the next snag: # rpm -Uvh util-linux-2.11n-1.i386.rpm error: failed dependencies: libc.so.6(GCC_3.0) is needed by util-linux-2.11n-1 Eh? A bit overenthusiastic for updates? After recompilation and installation of new binaries results are the same. Moreover, feeding from stdin an output of 'man colcrt' saved in a file has effects similar to those from the original report. But I think that I found an immediate culprit. 'col -b' chokes on "overstriking is destruc". This fragment examined with xdd looks like that: 00001a0: 2077 6869 6368 206f 7665 7273 7472 696b which overstrik 00001b0: 696e 6720 6973 2064 6573 7472 7563 ad0a ing is destruc.. 00001c0: 2020 2020 2074 6976 652e 2020 4861 6c66 tive. Half Note a character 0xad. After deleting it from input 'col -b' ceases to have problems but even 'col -b -p' stops in the same place. 0xad seems to be used for a hyphenation in an output of 'man'.
Comparing carefuly differences between systems where the bug occures and where it does not I found a way to cause it reliably anywhere. The following command does the trick: ( unset LANG ; man colcrt | col -b ) with "old" and "new" versions of util-linux as well. You can feed 'col -b' also with an output of 'man colcrt' and not from a pipe. At least when LANG is unset it trips. I did not check all possible settings of LANG. Actually this may be a bug in glibc or in man; a contents of 'man colcrt' seems to be LANG independent.
I can't reproduce it using your instructions. I tried it on a 7.0 system, a 7.1ish x86 system, a 7.[12]ish Alpha system, and a rawhide buildroot. The last line in all cases So, there is some pretty big disconnect here, I'm not sure what to do besides say "WORKSFORME", because it does.
What can I say? I just tried on two different systems running 7.2 distribution. One with _all_ current updates applied, the other one pretty close but few things missing yet. If LANG is set then everything is ok. The moment it is unset an output stops on "destruc". OTOH on a system when LANG is unset by a default when I will do: ( man colcrt | env LANG=en_CA col -b ) then everything is on my screen down to 3rd Berkeley Distribution June 30, 1993 3rd Berkeley Distribution line. How you cannot reproduce that, by unsetting LANG of course, is beyond my imagination. I just tried on a system where LANG is normally set and (unset LANG; man colcrt | col -b ) tripped it very nicely down to "with status 36096". :-) This "unprintable" 0xad is obviously stopping 'col' while 'nroff' is still producing it.
For extra bonus points I re-run this test on Alpha with 7.2-beta. On _that_ machine nroff output indeed does have 0x2d for a hyphen if LANG is not set and 0xad if it is. As this character is "printable" in both cases then 'col -b' does not have problems. I wonder why this difference? Why 'col -b' cannot just ignore all "garbage" characters does not matter from where they are coming from?