Bug 104542 - Many man pages fail to display with LANG=C
Summary: Many man pages fail to display with LANG=C
Status: CLOSED DUPLICATE of bug 103214
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: man
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-16 22:34 UTC by Need Real Name
Modified: 2007-04-18 16:57 UTC (History)
0 users

Clone Of:
Last Closed: 2006-02-21 18:58:35 UTC

Attachments (Terms of Use)

Description Need Real Name 2003-09-16 22:34:55 UTC
Description of problem:

Since I do not require UTF-8 support, I turned it off by setting LANG to C in my
shell configuration, as well as in /etc/sysconfig.  At about the same time, some
man pages stopped displaying properly, exiting with an "iconv: illegal input
sequence" error message.  The man pages that failed to display failed every
time.  The man pages that worked worked every time.

How reproducible:


Steps to Reproduce:
1. Execute this at the shell prompt:

LANG=C man lockf


LANG=en_US.iso88591 man lockf

Actual results:

iconv: illegal input sequence at position 126

Expected results:

lockf man page displayed.

Additional info:

At first I didn't connect disabling UTF-8 with `man' malfunctioning, but after a
serious attempt at debugging the problem, I made the connection.  Apparently, it
takes two things to trigger the bug:

1) The nroff source must contain raw Latin 1 characters.  (Comments count.)

2) LANG must at a non-UTF-8 setting.

`lockf' is a good example.  If you unzip /usr/share/man/man3/lockf.3.gz, you'll
notice a raw Latin 1 character.  Remove it and the man page works.

It seems that some part of `man' expects all manuals to be in UTF-8 when they're
clearly not.  Either the requirement should be dropped, or the man pages should
be all converted to UTF-8.  The latter solution doesn't address the problem of
third-party man pages getting installed to the system.  Perhaps a better
solution would be for man not to treat invalid UTF-8 sequences as fatal errors.

Comment 1 Eido Inoue 2003-09-17 15:23:25 UTC

*** This bug has been marked as a duplicate of 103214 ***

Comment 2 Red Hat Bugzilla 2006-02-21 18:58:35 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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