Bug 11643 - xterm ignores Xresources for 8bit I/O
xterm ignores Xresources for 8bit I/O
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: xterm-color (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-24 14:37 EDT by hajic
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-24 14:37:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description hajic 2000-05-24 14:37:43 EDT
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 14:42:15 EDT
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 14:52:36 EDT
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.