Bug 81003 - xman displays terminal control sequences
Summary: xman displays terminal control sequences
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-03 10:27 UTC by Derek Martin
Modified: 2007-04-18 16:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-25 10:15:07 UTC

Attachments (Terms of Use)

Description Derek Martin 2003-01-03 10:27:24 UTC
From Bugzilla Helper:
User-Agent:  Shhh... it's a secret

Description of problem:
When displaying a man page, xman displays ANSI (or VT100-compatible) terminal
control characters.  For example:

       rhnsd  -  a  program  for  quering  the Red Hat Network for updates and

       1mrhnsd 22m[4mOPTION24m]...

Etc...  Many man pages are virtually unreadable in xman.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run xman
2. display any man page


Actual Results:  as shown above

Expected Results:  Nicely formatted man page

Additional info:

I went so far as to create a brand-spankin' new user for testing, to make sure
this was not an environment thing.  This is a pretty fresh install of RH8.  I
don't remember which, but I chose one of the standard install options.


Comment 1 Michael Lee Yohe 2003-01-03 15:02:03 UTC

$ rpm -qf `which xman`

Comment 2 Mike A. Harris 2003-01-07 12:25:29 UTC
xman is a legacy application which is provided in the default XFree86 install,
but is not supported.  Please report this problem to XFree86.org by emailing
xfree86@xfree86.org  It is likely that this application is unmaintained now,
and may contain any number of bugs.  I'll likely remove it from my next
build as there are other GUI manpage viewers in the distribution.

Comment 3 Derek Martin 2003-01-07 19:21:34 UTC
Well, while I'm opposed to any major vendor not supporting "legacy" applications
from the XFree86 project, on the grounds that these applications are still
industry standard, and in many cases, still much better than their supposed
"replacements" from GNOME or KDE (even if their interfaces aren't quite as
pretty), if you're going to insist on such a policy, it's fine as long as it's
easy to find out what those replacements are.

So, what are they?  Assuming they're installed on my system, they don't seem to
have man pages, which makes it very difficult to identify them.

I would like to comment that, when supporting a mix of Linux and commercial Unix
environments, it is important for "legacy" X apps to work, in order to provide a
uniform environment for the users, since in many cases GNOME or KDE apps are not
an option on those platforms (or are prohibitive to build and make available). 
It's great for Linux to have a nice, pretty desktop environment, but the fact of
the matter is that many sites using Linux in more places than just the back room
are Unix shops, and are going to expect their Linux desktops to work like their
Unix workstations.  This means they expect "legacy" applications on Linux
systems to work properly.

It seems as though you're the only person supporting X at Red Hat, which is
unfortunate.  You obviously have too much to do, if that's the case.  But for
Red Hat to have a policy of not supporting "legacy" X applications is a cheesy
cop-out which is probably going to irritate a lot of people...  If it means that
these apps are going to start disappearing from the distribution, it will likely
mean that I will have to start looking at alternatives to Red Hat where I
support Unix on the desktop.

People like the older X apps, often even when newer, prettier alternatives from
the desktop projects are available, because:

 - they're accustomed to them, from working with them for decades
 - they often perform better than their GNOME or KDE counterparts (like xterm)
 - they are often more flexible and configurable, via X resources

Before GNOME or KDE can really replace these apps in the eyes of many
experienced Unix users, they need to address at least point #2, and preferably
point #3 as well.  I realize this isn't in your realm of control, but until that
happens, many people will not be satisfied with GNOME or KDE replacements.  They
simply (often) don't work as well or as flexibly, no matter how pretty they may be.

Comment 4 Derek Martin 2003-01-07 19:24:57 UTC
Oh, also I will report the bug to the XFree86 team, as you suggested.  If I
receive any useful information back from them as a result, I'll keep this bug
updated with such.

Comment 5 Mike A. Harris 2003-01-08 08:07:31 UTC
Rather than responding to your lengthy comment above, I'll suffice to say,
that if upstream fixes xman, or if someone provides a patch to upstream
which get's accepted and commited to CVS, I'm happy to re-enable xman.

This issue is extremely unimportant however priority-wise in relation to
the hundreds of other open bug reports, so I'd be lying to you if I said
I'd even attempt to debug it anytime soon.  Reporting it upstream is the
fastest way to finding a solution.

Comment 6 Derek Martin 2003-01-08 17:07:47 UTC
Actually this seems to be related to a change in groff, rather than a problem
per se with xman...  

I have a RH 7.2 system, against which I compared the operation of xman from Red
Hat 8.  On both systems, xman formats its man pages using the following sequence
of commands:

gzip -d -c /usr/share/man/manX/manpage.X.gz > /tmp/tempfile
cd /usr/share/man; soelim /tmp/tempfile | geqn |gtbl | groff -Tlatin1 -mandoc >>
/tmp/othertmpfile 2>/dev/null

On Red Hat 8, the output of these commands (i.e. the contents of
/tmp/othertmpfile) produces terminal control sequences.  On 7.2 (and I believe
all versions of Red Hat prior to 8.0), it produces output like this:

CAL(1)                  System General Commands Manual                  CAL(1)

     c^Hca^Hal^Hl - displays a calendar

     c^Hca^Hal^Hl [-^H-m^Hmj^Hjy^Hy1^H13^H3] [[_^Hm_^Ho_^Hn_^Ht_^Hh]

     C^HCa^Hal^Hl displays a simple calendar.  If arguments are not specified,
the cur­
     rent month is displayed.  The options are as follows:

     -^H-1^H1      Display single month output (use if cal was built with -3 as
             default to get older traditional output)

     -^H-3^H3      Display prev/current/next month output (use if cal was built with
             traditional -1 as default to get newer improved output)

     -^H-m^Hm      Display Monday as the first day of the week.  (The default is

     -^H-j^Hj      Display Julian dates (days one-based, numbered from January 1).

     -^H-y^Hy      Display a calendar for the current year.

     A single parameter specifies the year (1 - 9999) to be displayed; note
     the year must be fully specified: ``cal 89'' will _^Hn_^Ho_^Ht display a
     for 1989.  Two parameters denote the month (1 - 12) and year.  If no
     parameters are specified, the current month's calendar is displayed.

     A year starts on Jan 1.

     The Gregorian Reformation is assumed to have occurred in 1752 on the 3rd
     of September.  By this time, most countries had recognized the reforma­
     tion (although a few did not recognize it until the early 1900's.)  Ten
     days following that date were eliminated by the reformation, so the cal­
     endar for that month is a bit unusual.

     A c^Hca^Hal^Hl command appeared in Version 6 AT&T UNIX.

BSD                              June 6, 1993                              BSD

This is clearly the format expected by xman, as xman on 7.2 works perfectly. 
So, it appears that groff on RH8 is producing terminal control sequences when it
should not be.  My guess (off the top of my head, without looking at the groff
code) is that it's supposed to behave differently if the output is being sent to
a terminal than if it is not, and someone mistakenly removed the check to see if
the output file descriptor is a terminal.

I think this needs to be reopened and reassigned to whoever is in charge of groff...

Comment 7 Derek Martin 2003-01-08 17:24:30 UTC
Well, I have to rule out my theory above...  I used the following command:

  $ man cal | cat > tmpfile

The contents of tmpfile included the backspace method of underlining and bolding
text, rather than terminal control sequences.  So it's apparently not as simple
as different behavior when the output is a terminal or not, as it works at least
sometimes.  But it still seems to be a problem with groff (or perhaps one of its
components, i.e soelim, geqn, or gtbl).

Comment 8 Derek Martin 2003-01-08 18:56:56 UTC
Ok, it looks like this would have to be fixed in xman after all...  I've tracked
down the problem.

On systems using groff >= 1.18, xman is broken.  Newer versions of groff now use
"SGR escape sequences" by default, rather than ^H sequences, for underlining and
enboldening text.  In order to get the old behavior (compatible with xman), you
must call groff with the -c option.

See http://groff.ffii.org/ for details.

For such systems, the following patch should suffice to fix the
problem.  Ideally, this should probably get some sort of configurable
define, but I don't want to guess how the X team would want to go
about dealing with this...

# diff -u oldvendor.h vendor.h
--- oldvendor.h 2003-01-08 13:30:08.000000000 -0500
+++ vendor.h    2003-01-08 13:33:02.000000000 -0500
@@ -173,7 +173,7 @@
 # elif defined(BSD) && (BSD >= 199103)
 #  define FORMAT "| eqn | tbl | nroff -man"
 # elif defined(linux)
-#  define FORMAT "| geqn | gtbl | groff -Tlatin1 -mandoc"
+#  define FORMAT "| geqn | gtbl | groff -c -Tlatin1 -mandoc"
 # else
 #  define FORMAT "| neqn | nroff -man"      /* The format command. */
 # endif

Mike, his tiny patch can easily be added to your existing manconf patch -- it
even patches the same file.

For others who are tracking this bug, there is another workaround in the mean
time.  In your .bashrc, .profile, or some similar file, include the line:

  export GROFF_NO_SGR=1

For original Bourne shells, this would of course need to be:



Comment 9 Derek Martin 2003-01-08 18:59:22 UTC
Note: I have reported this to the XFree86 team as well...  Hopefully they'll fix
it upstream.

Comment 10 Mike A. Harris 2003-01-09 10:13:45 UTC
IMHO, there should be some runtime method of determining how to call
groff.  Otherwise it is rather impossible to have on XFree86 binary
package set work on more than one distribution, and even the source
code would require tweaking an option for one version of groff and not

I consider it to be a groff bug, if the behaviour changes this much
in between versions without changing the command line options.  I have
carbon copied our groff maintainer Florian Laroche for comment.

Comment 11 Need Real Name 2003-01-22 17:10:32 UTC

Just giving some positive feedback - above described fix works for me also.
$ export GROFF_NO_SGR=1  

I had originally posted in the Red Hat install list (jhijr@yahoo.com: "xman 
shows control characters"). Since I only receive the digest, my cut-and-paste 
replies often don't continue the thread, i.e. end up as separate entries in the 
archives. So I'm following up here.

John Ingersoll, Jr.

Comment 12 Mike A. Harris 2003-01-23 12:26:38 UTC
I'm leaving the official solution to this up to the XFree86 team.
Whatever they decide to put into XFree86 4.3.0 will be incorporated
into our source tree once the 4.3.0 release is made public.

I am defering this issue until the 4.3.0 release, after which time
you may feel free to reopen this from it's "DEFERRED" status.

Comment 13 Mike A. Harris 2003-04-25 10:15:07 UTC
xman is disabled in current builds, closing WONTFIX

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