Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 80847

Summary: man pages use funny characters
Product: [Retired] Red Hat Public Beta Reporter: ctm
Component: groffAssignee: Florian La Roche <laroche>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: low Docs Contact:
Priority: medium    
Version: phoebeCC: ltroan, michael.wardle, mitr, p.van.egdom, tao, twaugh, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-02-06 16:00:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 79578    
Description Flags
groff-1.18.1-multichar.patch none

Description ctm 2003-01-01 00:36:22 UTC
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-14 03:43:27 UTC
This is possibly related to -- or the cause of -- bug 75193, which is related
to man and groff and owned by

Comment 2 Eido Inoue 2003-01-14 04:38:51 UTC
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-14 04:39:31 UTC
I meant that it's not a groff bug, but rather the workaround is done in groff.

Comment 4 Miloslav Trmac 2003-01-14 08:04:49 UTC
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 10:29:46 UTC
Ok, groff-1.18.1-6 should have this finally resolved. I'll copy the src.rpm
in a second to, 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 22:42:09 UTC
groff-1.18.1-6 from 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 11:21:24 UTC
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 10:36:38 UTC

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 11:55:21 UTC
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 16:08:01 UTC
Created attachment 89681 [details]

This patch fixes it for me.

Comment 11 Tim Waugh 2003-01-29 17:27:29 UTC
*** Bug 80544 has been marked as a duplicate of this bug. ***

Comment 12 Bill Nottingham 2003-01-29 17:32:38 UTC
*** Bug 83023 has been marked as a duplicate of this bug. ***

Comment 13 Larry Troan 2003-01-29 17:42:34 UTC

Comment 14 David Balažic 2003-01-30 17:55:24 UTC
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 11:32:10 UTC
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 14:34:28 UTC
The theme seems to be underlined UTF-8 characters still being broken.

Comment 17 Tim Waugh 2003-02-03 17:59:08 UTC
It was due to less(1) being broken: see bugs 83376, 83377 (with patches).

Comment 18 Tim Waugh 2003-02-05 15:08:03 UTC
Can you still see problems with groff-1.18.1-10 and less-378-7 (both in rawhide

Comment 19 ctm 2003-02-05 16:15:57 UTC
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 17:09:31 UTC
less-378-7 is what you want.  Hold out for that.

Comment 21 ctm 2003-02-06 04:56:34 UTC
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 16:00:04 UTC
Things look pretty good with the re0206.nightly tree.  Closing out.