Bug 80847 - man pages use funny characters
man pages use funny characters
Product: Red Hat Public Beta
Classification: Retired
Component: groff (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Florian La Roche
Ben Levenson
: 80544 83023 (view as bug list)
Depends On:
Blocks: 79578
  Show dependency treegraph
Reported: 2002-12-31 19:36 EST by ctm
Modified: 2007-04-18 12:49 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-02-06 11:00:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
groff-1.18.1-multichar.patch (381 bytes, patch)
2003-01-29 11:08 EST, Tim Waugh
no flags Details | Diff

  None (edit)
Description ctm 2002-12-31 19:36:22 EST
Description of problem:
man pages now use something other than a - (0x2d) in places where a dash has
been previously used.  This makes it hard to search for a given command line
option using / from the pager or from xemacs.

M-x man in xemacs results in man pages with something other than the normal - to
represent the character that introduces a command line switch.  As such,
interactive searching, e.g. using C-s fails when you try to look up a command
line switch option the obvious way

Version-Release number of selected component (if applicable):
man-1.5j-12 (although it's probably not a bug in man itself--that's just where I
see the problem)

How reproducible:

Steps to Reproduce:
1. man man
2. /-C
Actual results:
Pattern not found

Expected results:
Portions of the man man page containing -C should be highlighted

Additional info:
in emacs it's even worse; the dashes result in a bunch of \342\210\... junk
Comment 1 Michael Wardle 2003-01-13 22:43:27 EST
This is possibly related to -- or the cause of -- bug 75193, which is related
to man and groff and owned by laroche@redhat.com.
Comment 2 Eido Inoue 2003-01-13 23:38:51 EST
yes, we've confirmed that it is a groff bug. 

the following approach (to be added in man.local and
mdoc.local) until programs can handle Unicode hyphens correctly:

.if '\*[.T]'utf8' \
.  char \- \N'45'

Comment 3 Eido Inoue 2003-01-13 23:39:31 EST
I meant that it's not a groff bug, but rather the workaround is done in groff.
Comment 4 Miloslav Trmac 2003-01-14 03:04:49 EST
Using the "real" hyphen is maybe OK for groff, but doesn't help
when you want to search and/or cut&paste an option name, because
most of us have no "hyphen" key on our keyboards.
Comment 5 Florian La Roche 2003-01-14 05:29:46 EST
Ok, groff-1.18.1-6 should have this finally resolved. I'll copy the src.rpm
in a second to http://people.redhat.com/laroche, let me know if this does not
work for you.

The changes from above are already in our rpm, but do not get properly applied.


Florian La Roche
Comment 6 ctm 2003-01-14 17:42:09 EST
groff-1.18.1-6 from http://people.redhat.com/laroche did not help, and in the
xemacs case it made things worse.  Now if I say

M-x man

the status line says

man man (cleaning...)

and xemacs runs forever.  doing a man man in a gnome-terminal results in a
question mark being printed where the minus sign should be.

I'm using groff-1.18.1-6 (from laroche) and xemacs-21.4.10-6 (from rawhide)

If I back off to groff-1.18.1-1 from the Phoebe ISO, the running forever and
question mark both go away, so groff-1.18.1-6 is indeed the culprit here.

Comment 7 Florian La Roche 2003-01-15 06:21:24 EST
This one is hunting me... release 7 is another try and I again see no
problems on the console. I have not tried xemacs with this.


Florian La Roche
Comment 8 Peter van Egdom 2003-01-26 05:36:38 EST

groff-1.18.1-7 does not fix the manpage bug :

- "man nfsstat" in konsole shows [strange character] [spaces] [description of
- "man nfsstat" in xterm shows [option] [spaces] [description of option].
- "man nfsstat" in gnome-terminal shows [question mark] [option] [spaces]
[description of option]
- "man nfsstat" in a text console shows [option] [description of option].

*The only way* for me to view a manpage correctly is "man <foo> |col -b |less".

"man nfsstat |col -b |less" shows [option] [hyphen] [spaces] [description of

- man-1.5k-2
- Red Hat Linux release 8.0.93 (Phoebe)

- LANG="nl_NL.UTF-8"
- SUPPORTED="nl_NL.UTF-8:nl_NL:nl:en_US.UTF-8:en_US:en"
- SYSFONT="latarcyrheb-sun16"

Comment 9 Peter van Egdom 2003-01-26 06:55:21 EST
Hmmgbf... I'll have to correct myself on comment #8. 

"man snmpwalk |col -b" also results in garbage output :

       The command:

       snmpwalkOsc‐publicv‐1 zeus system

       will retrieve all of the variables under system:
Comment 10 Tim Waugh 2003-01-29 11:08:01 EST
Created attachment 89681 [details]

This patch fixes it for me.
Comment 11 Tim Waugh 2003-01-29 12:27:29 EST
*** Bug 80544 has been marked as a duplicate of this bug. ***
Comment 12 Bill Nottingham 2003-01-29 12:32:38 EST
*** Bug 83023 has been marked as a duplicate of this bug. ***
Comment 13 Larry Troan 2003-01-29 12:42:34 EST
Comment 14 David Balažic 2003-01-30 12:55:24 EST
This is what I see on a fresh phoebe2 ( 8.0.93 ) system :

Running screen on VT2 as root; man init -> missing hyphens in the synopsis line.
similar problem in man sysctl and man nm.
man blockdev -> "-<a little sqare>setro" is displayed

Versions :
Comment 15 Peter van Egdom 2003-02-02 06:32:10 EST
Upgrading to "groff-1.18.1-9" solves _some_ of the reported problems with
manpages, however :

"man snmpwalk" in konsole and gnome-terminal seems fixed, but not in xterm.
"man nfsstat" in konsole and gnome-terminal seems fixed, but not in xterm.
"man crontab" in konsole, gnome-terminal, xterm and virtual console still shows
strange characters.
"man init" in konsole shows corruption on the second line of description and a
missing "-" in xterm.
Comment 16 Tim Waugh 2003-02-03 09:34:28 EST
The theme seems to be underlined UTF-8 characters still being broken.
Comment 17 Tim Waugh 2003-02-03 12:59:08 EST
It was due to less(1) being broken: see bugs 83376, 83377 (with patches).
Comment 18 Tim Waugh 2003-02-05 10:08:03 EST
Can you still see problems with groff-1.18.1-10 and less-378-7 (both in rawhide
Comment 19 ctm 2003-02-05 11:15:57 EST
groff-1.18.1-10 and less-378-6 (I didn't see less-378-7 on the rawhide mirror)
seem to solve the problems I've seen.  My testing so far has been light, but I
use the machine with phoebe 2 on it a lot and will keep my eye out for any
remaining glitches.
Comment 20 Tim Waugh 2003-02-05 12:09:31 EST
less-378-7 is what you want.  Hold out for that.
Comment 21 ctm 2003-02-05 23:56:34 EST
OK.  I picked up and installed less-378-7 and the problems still appear solved,
but my use of less is very lightly tested, since I almost always read man pages
under xemacs.
Comment 22 Jay Turner 2003-02-06 11:00:04 EST
Things look pretty good with the re0206.nightly tree.  Closing out.

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