Red Hat Bugzilla – Full Text Bug Listing
|Summary:||xman displays terminal control sequences|
|Product:||[Retired] Red Hat Linux||Reporter:||Derek Martin <code>|
|Component:||XFree86||Assignee:||Mike A. Harris <mharris>|
|Status:||CLOSED WONTFIX||QA Contact:||David Lawrence <dkl>|
|Version:||8.0||CC:||laroche, michael, shaygyi|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-04-25 06:15:07 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Derek Martin 2003-01-03 05:27:24 EST
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: 1MNAME0m rhnsd - a program for quering the Red Hat Network for updates and information 1mSYNOPSIS0m 1mrhnsd 22m[4mOPTION24m]... Etc... Many man pages are virtually unreadable in xman. Version-Release number of selected component (if applicable): How reproducible: Always 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. Thanks!
Comment 1 Michael Lee Yohe 2003-01-03 10:02:03 EST
Confirming. $ rpm -qf `which xman` XFree86-tools-4.2.0-72
Comment 2 Mike A. Harris 2003-01-07 07:25:29 EST
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 email@example.com 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 14:21:34 EST
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 14:24:57 EST
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 03:07:31 EST
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 12:07:47 EST
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) N^HNA^HAM^HME^HE c^Hca^Hal^Hl - displays a calendar S^HSY^HYN^HNO^HOP^HPS^HSI^HIS^HS c^Hca^Hal^Hl [-^H-m^Hmj^Hjy^Hy1^H13^H3] [[_^Hm_^Ho_^Hn_^Ht_^Hh] _^Hy_^He_^Ha_^Hr] D^HDE^HES^HSC^HCR^HRI^HIP^HPT^HTI^HIO^HON^HN 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 Sunday.) -^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 calendar 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. H^HHI^HIS^HST^HTO^HOR^HRY^HY 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 12:24:30 EST
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 13:56:56 EST
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: GROFF_NO_SGR=1; export GROFF_NO_SGR Cheers.
Comment 9 Derek Martin 2003-01-08 13:59:22 EST
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 05:13:45 EST
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 another. 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 12:10:32 EST
Derek, 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 (firstname.lastname@example.org: "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. Thanks, John Ingersoll, Jr.
Comment 12 Mike A. Harris 2003-01-23 07:26:38 EST
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 06:15:07 EDT
xman is disabled in current builds, closing WONTFIX