This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 115079 - missing JLESSCHARSET support
missing JLESSCHARSET support
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: less (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-06 06:25 EST by Akira TAGOH
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Akira TAGOH 2004-02-06 06:25:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4.1)
Gecko/20031114

Description of problem:
We did the UTF-8 transition for all laugnages, it means we support
UTF-8 *locale* and UTF-8 *encoding*, and we also want people to shift
their locale to UTF-8. but we dropped their native *locale*, but no
*encoding*. basically such problem doesn't appears when people uses
iso-8859-1, because it's compatible with UTF-8. but they still uses
their encoding in the plain text files and etc etc. to be done all
transition, I think we need to wait that it has been done in almost
the world.
I would know why you drop this.

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


How reproducible:
Always

Steps to Reproduce:
1.LANG=ja_JP.eucJP gnome-terminal --disable-factory
2.export LANG=ja_JP.eucJP
3.export JLESSCHARSET=japanese-euc
4.ls -l | less
    

Actual Results:  display broken strings on the date field.

Expected Results:  display correct Japanese

Additional info:
Comment 1 Karsten Hopp 2004-02-06 07:14:10 EST
There are several reasons: 
 
- those patches have a bad track record, they used to break support     
  for other encodings 
- there are conflicting copyrights in the japanese patches and less, 
  those patches should have never been added to our package in the  
  first place 
- FC2 is the testbed for RHEL4 as RHEL4 will inherit from FC2 and 
  its successors. This is where new packaages need to appear first 
  to get some testing. That's why I made the decision to update less 
  to version 381 and drop the ISO 2022 patch. If this means breaking 
  encodings for character sets such as ISO 646 (German) or  
  JIS X 0208:1997 (Japanese), so be it. We (Red Hat) decided to use 
  UTF-8, even if this means that some customers have to swallow the  
  bitter pill.  
- The japanese patches aren't maintained since 2000. 
- the old patches don't work with current less versions 
- porting the patches takes considerable amount of time for porting 
  and testing to be sure that they don't break other 
  locales/encodings 
- I'm not going to maintain patches for another 5 years (RHEL4) 
  which are already 4 years unmaintained upstream. 
- we can't keep the old less version due to several UTF-8 bugs. 
  And Red Hat's decision was to use UTF8, not ISO 2022. 
- FC2 is the place where such incompabilities to older versions can 
  happen 
- If you want a pager which supports japanese encodings, add a line 
 export PAGER=lv 
  to bashrc or profile  
   
Comment 2 Akira TAGOH 2004-02-07 17:51:21 EST
I see. these statement is good enough to understand. and it will be a
reson which we can't drop lv then :)

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