Red Hat Bugzilla – Bug 251064
nroff ignores -T option contrary to what the man page says
Last modified: 2007-11-30 17:12:12 EST
Description of problem: nroff ignores -T<encoding> option contrary to what the man page says. Also, the man page says that when no -T option is given, it should consult LC_ALL, LC_CTYPE, LANG, and LESSCHARSET environment variables to determine the output device (in this case, encoding), which it does not do. The bad side of this has to do with viewing man pages in Midnight Commander, which only correctly displays 8-bit output. If 'locale charmap' returns UTF-8, then man pages formatted with nroff will have multi-byte characters (e.g., single quotes), which will be displayed incorrectly in MC. Moreover, this cannot be corrected by specifying a -T option for nroff in man.config file, as the documentation would suggest. Version-Release number of selected component (if applicable): GNU nroff (groff) with Red Hat i18n/l10n support GNU groff version 1.18.1.4 How reproducible: The nroff shell script contains: case $1 in ... -[eq] | -s* | -u* | -T* ) # ignore these options ;; Also, the only assignment to the variable charset_out, which is used as the output encoding, is based on the output of 'locale charmap' command. Additional info: I believe either documentation or the code should be changed.
I'm not sure if this problem isn't occuring because of my desktop settings. I try to play with some encoding but nroff supports only ascii, ascii8, latin1, utf8, nippon, and cp1047. Here I have problem with correct fonts for nippon. In other cases it seems ok. I can try reproduce problem, if I have more data (language, encoding which you use as default etc).
To formally show the problem, I did the following in bash (my comments are surrounded by ***): ~> export LC_ALL=en_US.iso88591 ~> locale charmap ISO-8859-1 ~> locate en/man1/man.1 /usr/share/man/en/man1/man.1.gz ~> zcat /usr/share/man/en/man1/man.1.gz | nroff | cat -v | grep '\^' *** No output is given here, i.e., there are no non-ASCII characters in the output of nroff *** ~> export LC_ALL=en_US.utf8 ~> locale charmap UTF-8 ~> zcat /usr/share/man/en/man1/man.1.gz | nroff -Tlatin1 | cat -v | grep '\^' man M-bM-^HM-^R format and display the on-line manual pages preformatted page is corrupted. DonM-bM-^@M-^Yt actually display the man DonM-bM-^@M-^Yt actually display the man pages, but do print the loca- "manpath" is equivalent to "man --path". Like M-bM-^HM-^Rw, but print file But in the normal case where doesnM-bM-^@M-^Yt contain a slash, searches a list of the directories that searches. If you donM-bM-^@M-^Yt specify but list of the directories that searches. If you donM-bM-^@M-^Yt specify an search path (weM-bM-^@M-^Yll call it a "command directory") for which you number and possibly a compression suffix. If it doesnM-bM-^@M-^Yt find M-bM-^@M-^XLANG=dk man 1 fooM-bM-^@M-^Y will cause man to look for the foo man page If you see blinking \255 or <AD> instead of hyphens, put M-bM-^@M-^XLESS- CHARSET=latin1M-bM-^@M-^Y in your environment. If you add the line *** There are many lines with non-ASCII characters despite -Tlatin1 option of nroff. The non-ASCII characters come in particular from Unicode apostrophes in words like "don't" and "doesn't". *** It seems that I have a truncated version of nroff, which is a shell script. I have the same version on my work machine with FC5. However, on our server there is a full version that contains the code: -Tascii | -Tlatin1 | -Tutf8 | -Tcp1047 | -Tascii8 | -Tnippon) T=$1 ;; In contrast, short Fedora versions have only -[eq] | -s* | -u* | -T* ) # ignore these options ;; The short version also does not contain the code that looks at LC_ALL, LC_CTYPE, LANG, and LESSCHARSET environment variables.
Now I see, you are reporting FC-5 bug on FC-7. FC-5 has version groff-1.18.1.1 and in FC-7 is groff-1.18.1.4, where is nroff with options (-Tascii | -Tlatin1 | -Tutf8 | -Tcp1047 | -Tascii8 | -Tnippon)). And the other issue isn't occuring on my computers (FC-6, FC-7, devel). I have no output in both examples.
I wrote in the first description of the bug that my version of groff is 1.18.1.4. And I have Fedora 7. Fedora 5 is at work. To make sure, I removed the groff package using package manager and checked that /usr/bin/nroff is gone. Then I installed it back (again using package manager), and bingo: I got the same truncated version of nroff. Could you check Fedora repositories? Now I cannot reinstall redhat-lsb-3.1-14.fc7 package, which was removed because of the dependencies when I removed groff. I get this message "failure: repodata/filelists.sqlite.bz2 from livna: [Errno 256] No more mirrors to try"...
If you are removing packages with dependecies it's better used rpm -e --nodeps groff. I'm sure that redhat-lsb can't be on livna, check your repositories in /etc/yum.repos/. My nearest two mirrors have the correct version of groff, find your nearest mirror and check, whether is updated. For example my mirror, which I used is ok: http://sunsite.mff.cuni.cz/MIRRORS/fedora.redhat.com/linux/releases/7/Fedora/i386/os/Fedora/groff-1.18.1.4-2.i386.rpm
Are you sure that this repository is OK? I downloaded the file to which you gave the link, went inside (using Midnight Commander), and nroff file again contains these lines: -[eq] | -s* | -u* | -T* ) # ignore these options ;; Besides, I checked all mirrors in France produced by http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-7&arch=i386 and they also all have truncated nroff.
Oh, now I see, in the installed version is change for default utf-8. I change it for option -Tencoding, so now should it work as you want. I'll update it in few days, please let me know, if something goes wrong.
groff-1.18.1.4-6.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
groff-1.18.1.4-6.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.