Red Hat Bugzilla – Bug 57715
Last modified: 2007-04-18 12:38:47 EDT
Description of Problem:
Watch this (long lines broken for display purposes):
$ man colcrt | col -b
COLCRT(1) System General Commands Manual COLCRT(1)
colcrt - filter nroff output for CRT previewing
colcrt [-] [-2] [file ...]
Colcrt provides virtual half-line and reverse line feed sequences for
terminals without such capability, and on which overstriking is
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
Version-Release number of selected component (if applicable):
util-linux-2.11f-17 and all other current updates for RH 7.2.
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:
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
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.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?