Bug 88524 - program can not write latin2 (accent) �� etc. chars to stdout
Summary: program can not write latin2 (accent) �� etc. chars to stdout
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 9
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-10 17:13 UTC by Boldizsar Nagy
Modified: 2016-11-24 14:59 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-03 11:15:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Boldizsar Nagy 2003-04-10 17:13:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
[boldi@hades sysconfig]$ cat i18n
LANG="hu_HU.UTF-8"5
LC_ALL="hu_HU.UTF-8"2-3
SUPPORTED="hu_HU:hu"23
SYSFONT="latarcyrheb-sun16"

[boldi@hades sysconfig]$ cat keyboard
KEYBOARDTYPE="pc"
KEYTABLE="hu101"

part of inputrc:
set meta-flag on
set input-meta on
set convert-meta off
set output-meta on

Some programs can not write latin2 chars to the stdout.
Eg.
[boldi@hades etc]$ echo �
�
It works, I can write those chars from my keyboard, but
[boldi@hades IHM_-_Valosag_Shokk]$ id3ed -i 04.-.Zarjon_be_a_bolt.mp3
04.-.Zarjon_be_a_bolt.mp3: (tag v1.1)
songname: Zrjon be a bolt
           ^
           | here should be an � (a') character, but did not appear.
Id3ed (from tar.gz) and cdlabelgen (shipped with RH 9) is installed.
Also when I pass an artist and a title to cdlabelgen which contains laint2
chars. The printed cover contains instead of one latin2 char 3-4 other (some
cyrill) characters.

But I have problems with java too. I tried with 1.4.1 from blackdown and
1.4.2beta from Sun and here are "squares" insted of the expected �� etc. chars.
Input of these chars works here too.

Version-Release number of selected component (if applicable):
bash-2.05b-20

How reproducible:
Always

Comment 1 Tim Waugh 2003-05-12 09:54:12 UTC
Not a bash problem.

Comment 2 Jakub Jelinek 2003-05-14 07:07:18 UTC
Is your filename UTF-8 encoded? If not, then you certaiunly cannot print it when using UTF-8 locale, unless you convert the filename
(e.g. using iconv(1) ).

Comment 3 Boldizsar Nagy 2003-05-14 14:17:00 UTC
No it is not. I solved the problem by changing the i18n file to:
LANG="hu_HU.ISO-8859-2"
LC_ALL="hu_HU.ISO-8859-2"
SUPPORTED="hu_HU:hu:en_US:en"
SYSFONT="lat2-sun16.psfu.gz"

And for X I installed:
XFree86-ISO8859-2-75dpi-fonts-4.3.0-2
XFree86-ISO8859-2-100dpi-fonts-4.3.0-2
packages.

And attached these lines to /etc/X11/fs/config:
        /usr/share/fonts/ISO8859-2/100dpi,
        /usr/share/fonts/ISO8859-2/75dpi,
after these lines:

# where to look for fonts
#
catalogue = /usr/share/fonts/ISO8859-2/misc,

Now everything works, but now I can not add new menu item manually to RedHat
menus. But I will try iconv function to convert the files to UTF-8.

Comment 4 Jakub Jelinek 2003-10-03 11:15:50 UTC
It is certainly preferable to convert your filenames and start using UTF-8.


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