Bug 949279

Summary:	provide a way to disable the 256 color feature
Product:	[Fedora] Fedora	Reporter:	Enrico Scholz <rh-bugzilla>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	iarlyy, jonathan, lnykryn, notting, pbrady, plautrba, rvokal, vpavlin
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-04-08 12:32:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Enrico Scholz 2013-04-07 12:12:57 UTC

Description of problem:

The 256 color terminal feature might be fine on the local machine but causes huge compatibility problems when working on remote machines:

$ screen
$ ssh paris        (CentOS 5.9 host)
$ less x1
WARNING: terminal is not fully functional
x1  (press RETURN)
$ logout
'screen-256color': unknown terminal type.


For long term, the remote machines will get perhaps knowledge about the new 256color terminal types.  But I do not see this happen in the next 2-3 years.

Only viable solution for me is the fallback to the non 256color modes.  Unfortunately, /etc/profile.d/256term.sh was written in a way which makes it very difficult to revert its actions.

Hence, please provide a way to disable the 256 color feature within ~/.bash_profile. E.g. by honoring a NO_256_COLORS=1 variable.


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

initscripts-9.42.2-3.fc18.x86_64

Comment 1 Lukáš Nykrýn 2013-04-08 11:04:20 UTC

If I am not mistaken, ~/.bash_profile is read after executing /etc/profile.d/256term.sh, so I does not help to add any option there. I am adding owner of this feature to CC, maybe he can provide some hints.

Comment 2 Enrico Scholz 2013-04-08 11:54:43 UTC

In the default case (no '-ls' xterm flag, no 'shell -/bin/bash' option in ~/.screenrc), only ~/.bashrc should be executed (which calls /etc/bashrc iterating through /etc/profile.d).

When setting one of the options above, overriding in ~/.bash* is not possible indeed (--> /etc/profile, then ~/.bash_profile execution order).  But having an option in /etc/profile.d/256term.sh to disable 256 colors, allows in this case e.g. a proprietary /etc/profile.d/00-local.sh script with something like

| ! test -e $HOME/.no-256-colors || NO_256_COLORS=1

(adding a single local file is much easier than to modify a file from the initscripts package).

Comment 3 Pádraig Brady 2013-04-08 12:19:10 UTC

3 options available currently.
I thought this was sufficient rather than adding another config var...

1. As per the "Release Notes" section on the feature page:
https://fedoraproject.org/wiki/Features/256_Color_Terminals
you could avoid on your remote system by adding the following to ~/.profile:

if test "SSH_CONNECTION"; then
  case "$TERM" in
  screen*) export TERM=screen;;
  *) export TERM=xterm;;
  esac
fi

2. Or you could update the remote system as per:
http://serverfault.com/questions/364655/how-do-you-get-term-screen-256color-on-centos-5-7

3. Or you can add this to a local setup script that is
run _after_ /etc/profile.d/*
I.E. at the bottom of your ~/.bashrc for example

test "$TERM" = screen-256color && export TERM=screen

Comment 4 Lukáš Nykrýn 2013-04-08 12:32:12 UTC

Thanks for quick response. I think that these three solutions (workarounds) are quite sufficient, so I will close this as wontfix.

If you have any other objection/suggestion, please feel free to reopen this bug.