Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 120819 - lang.sh shouldn't set CJK locale on virtual console
Summary: lang.sh shouldn't set CJK locale on virtual console
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks: 171491 FC6Target
TreeView+ depends on / blocked
 
Reported: 2004-04-14 07:02 UTC by Jens Petersen
Modified: 2014-03-17 02:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-11-06 20:11:55 UTC


Attachments (Terms of Use)
Patch to fallback to C locale for CJK in vt interactive shell (deleted)
2004-04-14 07:03 UTC, Jens Petersen
no flags Details | Diff
lang.sh.patch (deleted)
2006-10-18 04:14 UTC, Jens Petersen
no flags Details | Diff
patch for this issue (deleted)
2006-10-18 16:21 UTC, Bill Nottingham
no flags Details
lang.sh.patch2 (deleted)
2006-10-19 09:09 UTC, Jens Petersen
no flags Details | Diff

Description Jens Petersen 2004-04-14 07:02:00 UTC
Description of problem:
The virtual console doesn't have any font for CJK and my understanding
is that it won't happen any time in the near future either.

How reproducible:
every time

Steps to Reproduce:
1. Set system or user locale to ja_JP.UTF-8 in (/etc/sysconfig/i18n or
   ~/.i18n)
2. Login to virtual console
3. $ date
4. $ ls --help
5. etc, etc
  
Actual results:
White boxes instead of Japanese text.

Expected results:
Japanese text, but failing that falling back to LANG=C
say would be much better.

Comment 1 Jens Petersen 2004-04-14 07:03:38 UTC
Created attachment 99396 [details]
Patch to fallback to C locale for CJK in vt interactive shell

Comment 2 Bill Nottingham 2004-04-14 20:02:43 UTC
C is bad, as you drop UTF-8.

en_US.UTF-8 is probably better.

But getting a better virtual console is the right fix. :)

Comment 3 Eido Inoue 2004-04-14 20:14:42 UTC
What is you then launched something like bterm? You'd have to change
the env vars back to the ja ones?



Comment 4 Jens Petersen 2004-04-15 01:31:34 UTC
Bill, en_US.UTF-8 is fine. :)

Adrian, the above patch works fine with kon2.
It doesn't seem to work right with bterm though
for some reason (in fc1 at least - I can't test in fc2,
since it segfaults (cf bug 113910).
[Btw why doesn't PS1 get set when bterm starts?]

Comment 5 Eido Inoue 2004-04-15 20:27:21 UTC
comment 4: I can modify bterm to set PS1. bterm was originally put in
as a quick hack to do CJK UTF-8 in text mode.

I imagine the shell that bterm launches needs to be passed the
"interactive" flag and that would setup PS1 and other needed variables.

Comment 6 Bill Nottingham 2004-04-15 20:34:42 UTC
WHy is the check for PS1 there anyway?

Comment 7 Jens Petersen 2004-04-16 04:11:32 UTC
To check that it is an interactive shell. :)
Perhaps there is a better way of doing that?

Otherwise init runs in the fallback locale too...

Comment 8 Bill Nottingham 2004-04-16 04:32:20 UTC
Hm. But, really... do you *ever* want to run an app in CJK locale on a VT?

Comment 9 Jens Petersen 2004-04-16 05:30:00 UTC
Well for me falling back by default on a vt for interactive shells
for CJK is ok.  Except for kon and bterm I can't think of any way
to display CJK on vt's.

(We definitely don't want to fallback for non-interactive shells.)

Comment 10 Jens Petersen 2004-04-16 12:57:34 UTC
However I noticed that with the patch startx goes into the
fallback locale (like bterm) does: though "LANG=ja_JP.UTF-8 startx"
works. :)

Comment 11 Eido Inoue 2004-04-16 13:44:02 UTC
Comment 8: the people that like to run CJK on the VT are people with
low power machines that aren't meaty enough for X. And it's a question
of equality-- if you can do it in English, you should be able to do it
in CJK, so the rational goes.

I guess if you're doing server maintennance on the console and you
/must/ edit a non-English text file, to try to think of a realistic
example. But I'm stretching.

Comment 12 Bill Nottingham 2005-09-30 21:14:24 UTC
Is this still relevant, or is this fixed?

Comment 13 Jens Petersen 2005-10-03 10:37:23 UTC
Still happens with rawhide.

Comment 16 David Lawrence 2006-04-18 20:06:19 UTC
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.

Comment 17 Jens Petersen 2006-10-18 03:46:57 UTC
(In reply to comment #9)
> (We definitely don't want to fallback for non-interactive shells.)

Actually it would be better if Asian locale could also be supressed when booting
until rhgb starts. But perhaps that could be handled separately by the init system?

I think the basic idea of the original patch is still good.  Is there a more
elegant approach?

Comment 18 Jens Petersen 2006-10-18 04:14:41 UTC
Created attachment 138745 [details]
lang.sh.patch

updated patch against current lang.sh

Comment 19 Bill Nottingham 2006-10-18 16:14:45 UTC
Here's a better version.

Improvements:
- handles the non-UTF-8 case
- doesn't override en_IN
- catches tcsh as well

Bugs remaining, may not be sanely fixable:
- If you have ja_JP.eucjp, zh_CN.gb18030, we will end up changing the effective
charset.


Comment 20 Bill Nottingham 2006-10-18 16:21:46 UTC
Created attachment 138805 [details]
patch for this issue

Comment 21 Jens Petersen 2006-10-19 00:32:41 UTC
Thanks.

Should I open a separate bug for the boot message problem?

Comment 22 Jens Petersen 2006-10-19 00:43:37 UTC
> - If you have ja_JP.eucjp, zh_CN.gb18030, we will end up changing the effective
> charset.

I don't think that is a big problem.

It would probably be good to test the bogl too.

Another case that is harder to catch: ssh from a VC.

Comment 23 Bill Nottingham 2006-10-19 03:35:59 UTC
I didn't see a boot message problem in initial testing.

Comment 24 Jens Petersen 2006-10-19 04:19:58 UTC
Well it is really only the date setting line which still shows white boxes for me.
A detail, but it would be nice to get rid of them finally.

Comment 25 Jens Petersen 2006-10-19 09:01:23 UTC
I tested bogl and since it doesn't use a login shell the locale is the same as
on the console, but I think the functionality of the patch is good enough.

Comment 26 Jens Petersen 2006-10-19 09:09:38 UTC
Created attachment 138870 [details]
lang.sh.patch2

Maybe this is simpler for maintenance.

Comment 27 Bill Nottingham 2006-10-19 16:45:36 UTC
Hm, possibly, although it's already committed to CVS in the prior version. :)

For the date, it's being done through a pipe. It can be changed to LANG=$LANG
date... which breaks all the translations. That's sed-able, though.

Comment 28 Bill Nottingham 2006-10-19 17:28:38 UTC
Well, except for the part where LANG=$LANG date doesn't work right. :)

Comment 29 Bill Nottingham 2006-10-19 17:34:31 UTC
Fixed in CVS, will be in 8.46-1, potentially 8.45.4-1.

Comment 30 Fedora Update System 2006-10-31 03:13:36 UTC
initscripts-8.45.4-1 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 31 Jens Petersen 2006-10-31 03:26:01 UTC
I realised yesterday that the change seems to affect gdm's GUI:
ie it comes up in English now for CJKI locale.

Comment 32 Fedora Update System 2006-11-06 19:54:37 UTC
initscripts-8.45.5-1 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 33 Jens Petersen 2006-11-07 01:17:35 UTC
Any comments on comment 31 or am I way off?

Comment 34 Bill Nottingham 2006-11-07 01:25:17 UTC
A change was added for that.


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