Description of problem: "man strtok" returns this error: illegal input sequence at position 1292 Version-Release number of selected component (if applicable): 1.53-3 How reproducible: Always Steps to Reproduce: 1. Open xterm 2. Type "man strtok" Actual results: >man strtok iconv: illegal input sequence at position 1292 Expected results: The man page should be displayed. Additional info: I believe I have identified the source of this problem. By ungzipping the man page strtok.3.gz, and trying to run nroff on it manually I get this: >nroff strtok.3 iconv: illegal input sequence at position 1190 This byte position in the file is a hex E1, and should show up as a forward-accented 'a' character. I believe the correct UTF-8 sequence for that character should be C3 A1.
Created attachment 90939 [details] Proposed patch to fix strtok.3 man page
This is not related to strtok Actually, *many* man pages are unreadable with RH9. fontconfig is one of them (illegal input char at position 205). cdrecord is another one. test is yet another one... It's wrong in the first place to assume that man pages contain UTF-8 data. 99.95% of the pages not in plain 7-bit ascii contain iso-latin-1 chars (like the copyright sign, for instance). Therefore, the culprit is the /usr/bin/nroff script. The UTF-8 on line 112 should not be there, IMHO. Or RH assumes the work of converting all the man pages to UTF-8. Cheers, E.
Created attachment 91893 [details] Script to find problematic manual pages Having encountered the "iconv" error with "man", and seeing that others are having the same problem, I thought it might be useful to see what other pages suffered from the problem. So this script was born.
Created attachment 91894 [details] Sample output of badman.out, from RHL 9 system Sample of output generated by the attached "badman.sh" script. Generated on a Red Hat Linux 9 system. The RHL 9 system is not a full install, so a great many man pages included with 9 are not represented.
*** This bug has been marked as a duplicate of 98969 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.