Bug 61294 - Messages are broken in non-ASCII locales for libc strings
Messages are broken in non-ASCII locales for libc strings
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: enscript (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-16 09:03 EST by Göran Uddeborg
Modified: 2007-04-18 12:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-16 09:04:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to bind the codeset for libc strings. (488 bytes, patch)
2002-03-16 09:04 EST, Göran Uddeborg
no flags Details | Diff

  None (edit)
Description Göran Uddeborg 2002-03-16 09:03:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020301

Description of problem:
Enscript does setlocale only for LC_MESSAGES, not for LC_CTYPE.  That fails with
recent glibc versions which tries to convert to the selected character set
on-the-fly.  The result is non-ASCII character replaced by question marks.  For
some reason I don't understand, this appears to happen only to strings coming
from libc, not enscript's own strings.

Version-Release number of selected component (if applicable):1.6.1-16.2


How reproducible:
Always

Steps to Reproduce:
1.env LANG=fr_FR enscript /etc/passwd -o /apa

Actual Results:  enscript: Ne peut crier un fichier de sortie "/apa": Permission
non accord?e.

(In case it get's mangled in the processing, the middle character in the fourth
word is an e-acute.)

Expected Results:  The question mark which is before the e at the end should
(also) have been an e-acute.

Additional info:

I've mentioned this to the developer Markku Rossi <mtr@iki.fi>, so we can hope
it will be fixed in some future version of enscript.  In the mean time, maybe
the simple patch I encolse could be used.  I don't dare to do a
setlocale(LC_CTYPE,...) since enscript uses ctype functions and I haven't
analysed it enough to know if it would be affected.  But using the
bind_textdomain_codeset() ought to be safe.  If this were to be ported to the
distribution, one would of course have to adjust the configuration, similar to
what I suggested in bug 49182.
Comment 1 Göran Uddeborg 2002-03-16 09:04:52 EST
Created attachment 48725 [details]
Patch to bind the codeset for libc strings.
Comment 2 Tim Waugh 2002-03-18 07:00:06 EST
Fixed package is enscript-1.6.1-18.  Thanks.

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