Bug 57715 - wierd col
Summary: wierd col
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: util-linux   
(Show other bugs)
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-20 00:37 UTC by Michal Jaegermann
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-01 03:48:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2001-12-20 00:37:46 UTC
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.

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.

Comment 1 Michal Jaegermann 2001-12-20 16:57:20 UTC
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".

Comment 2 Elliot Lee 2001-12-31 18:05:41 UTC
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...

Comment 3 Michal Jaegermann 2001-12-31 20:23:11 UTC
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
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?).

Comment 4 Elliot Lee 2001-12-31 20:30:21 UTC
Erk, stupid httpd settings, I added an index.html that should get you what you need.

Comment 5 Michal Jaegermann 2002-01-01 02:57:31 UTC
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'.

Comment 6 Michal Jaegermann 2002-01-01 03:48:42 UTC
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.

Comment 7 Elliot Lee 2002-01-29 21:20:59 UTC
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.

Comment 8 Michal Jaegermann 2002-01-29 22:11:16 UTC
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.

Comment 9 Michal Jaegermann 2002-01-29 22:40:06 UTC
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?

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