Bug 11643 - xterm ignores Xresources for 8bit I/O
Summary: xterm ignores Xresources for 8bit I/O
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xterm-color   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-05-24 18:37 UTC by hajic
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-24 18:37:43 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 hajic 2000-05-24 18:37:43 UTC
xterm would only do 8-bit input if LANG is set (which is *not* what
I want, since other programs do not like LANG being set, for various
reasons!), ignoring effectively
xterm*eightBitInput:    true
xterm*eightBitOutput:   true
settings.

-- Jan Hajic

Comment 1 Preston Brown 2000-07-14 18:42:15 UTC
without LANG being set, Xterm assumes 7 bit POSIX locale, which is correct
behaviour.  This is not a bug, despite you not liking the behaviour.

Comment 2 hajic 2000-07-14 18:52:36 UTC
OK guys, but we all know that ``correct'' is not always correct. So someone
should take care of this; either .Xresources should not pretend they are setting
8-bit clean behaviour, when they are not, or xterm should get a parameter (such
as sort recently got, which I like very much: it's called -l) which instructs
Xterm to consider LANG etc (without -l, Xterm would simply ignore any NLS
settings!). Otherwise, adding environment-dependend behaviour (not only for
xterm but in general for *any* programs!!) is killing backward-compatibility and
driving application folks crazy!!! No one taught you that ``side effects''
should be avoided?? (Which is exactly what envirinment variables do...)

Please forward to whoever is responsible for Xterm.



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