Bug 80847
| Summary: | man pages use funny characters | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Public Beta | Reporter: | ctm | ||||
| Component: | groff | Assignee: | Florian La Roche <laroche> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | phoebe | CC: | ltroan, michael.wardle, mitr, p.van.egdom, tao, twaugh, twoerner | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| 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: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 79578 | ||||||
| Attachments: |
|
||||||
This is possibly related to -- or the cause of -- bug 75193, which is related to man and groff and owned by laroche. 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' I meant that it's not a groff bug, but rather the workaround is done in groff. 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. 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. greetings, Florian La Roche 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 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. 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. greetings, Florian La Roche Florian, groff-1.18.1-7 does not fix the manpage bug : - "man nfsstat" in konsole shows [strange character] [spaces] [description of option]. - "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 option]. - 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" Hmmgbf... I'll have to correct myself on comment #8. "man snmpwalk |col -b" also results in garbage output : <snip> EXAMPLE The command: snmpwalkOscâpublicvâ1 zeus system will retrieve all of the variables under system: <snip> Created attachment 89681 [details]
groff-1.18.1-multichar.patch
This patch fixes it for me.
*** Bug 80544 has been marked as a duplicate of this bug. *** *** Bug 83023 has been marked as a duplicate of this bug. *** THIS IS ISSUE TRACKER 14333, ENTERED BY DELL DURING GINGIN BETA4 AS SEVERITY 2. 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 : screen-3.9.13-2 groff-1.18.1-7 SysVinit-2.84-7 man-1.5k-2 procps-2.0.10-4 binutils-2.13.90.0.16-3 util-linux-2.11y-2 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. The theme seems to be underlined UTF-8 characters still being broken. Can you still see problems with groff-1.18.1-10 and less-378-7 (both in rawhide now)? 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. less-378-7 is what you want. Hold out for that. 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. Things look pretty good with the re0206.nightly tree. Closing out. |
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: 100% Steps to Reproduce: 1. man man 2. /-C 3. 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