This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 120819 - lang.sh shouldn't set CJK locale on virtual console
lang.sh shouldn't set CJK locale on virtual console
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
: i18n
Depends On:
Blocks: 171491 FC6Target 209579
  Show dependency treegraph
 
Reported: 2004-04-14 03:02 EDT by Jens Petersen
Modified: 2014-03-16 22:44 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-06 15:11:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to fallback to C locale for CJK in vt interactive shell (485 bytes, patch)
2004-04-14 03:03 EDT, Jens Petersen
no flags Details | Diff
lang.sh.patch (596 bytes, patch)
2006-10-18 00:14 EDT, Jens Petersen
no flags Details | Diff
patch for this issue (1.98 KB, text/plain)
2006-10-18 12:21 EDT, Bill Nottingham
no flags Details
lang.sh.patch2 (1.09 KB, patch)
2006-10-19 05:09 EDT, Jens Petersen
no flags Details | Diff

  None (edit)
Description Jens Petersen 2004-04-14 03:02:00 EDT
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 03:03:38 EDT
Created attachment 99396 [details]
Patch to fallback to C locale for CJK in vt interactive shell
Comment 2 Bill Nottingham 2004-04-14 16:02:43 EDT
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 16:14:42 EDT
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-14 21:31:34 EDT
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 16:27:21 EDT
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 16:34:42 EDT
WHy is the check for PS1 there anyway?
Comment 7 Jens Petersen 2004-04-16 00:11:32 EDT
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 00:32:20 EDT
Hm. But, really... do you *ever* want to run an app in CJK locale on a VT?
Comment 9 Jens Petersen 2004-04-16 01:30:00 EDT
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 08:57:34 EDT
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 09:44:02 EDT
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 17:14:24 EDT
Is this still relevant, or is this fixed?
Comment 13 Jens Petersen 2005-10-03 06:37:23 EDT
Still happens with rawhide.
Comment 16 David Lawrence 2006-04-18 16:06:19 EDT
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
Comment 17 Jens Petersen 2006-10-17 23:46:57 EDT
(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 00:14:41 EDT
Created attachment 138745 [details]
lang.sh.patch

updated patch against current lang.sh
Comment 19 Bill Nottingham 2006-10-18 12:14:45 EDT
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 12:21:46 EDT
Created attachment 138805 [details]
patch for this issue
Comment 21 Jens Petersen 2006-10-18 20:32:41 EDT
Thanks.

Should I open a separate bug for the boot message problem?
Comment 22 Jens Petersen 2006-10-18 20:43:37 EDT
> - 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-18 23:35:59 EDT
I didn't see a boot message problem in initial testing.
Comment 24 Jens Petersen 2006-10-19 00:19:58 EDT
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 05:01:23 EDT
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 05:09:38 EDT
Created attachment 138870 [details]
lang.sh.patch2

Maybe this is simpler for maintenance.
Comment 27 Bill Nottingham 2006-10-19 12:45:36 EDT
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 13:28:38 EDT
Well, except for the part where LANG=$LANG date doesn't work right. :)
Comment 29 Bill Nottingham 2006-10-19 13:34:31 EDT
Fixed in CVS, will be in 8.46-1, potentially 8.45.4-1.
Comment 30 Fedora Update System 2006-10-30 22:13:36 EST
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-30 22:26:01 EST
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 14:54:37 EST
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-06 20:17:35 EST
Any comments on comment 31 or am I way off?
Comment 34 Bill Nottingham 2006-11-06 20:25:17 EST
A change was added for that.

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