No edit summary |
No edit summary |
||
| Line 15: | Line 15: | ||
* Why is it better to add a script to /etc/profiles.d than to patch specific terminal emulators to set TERM to a 256-color version? This would allow e.g. gnome-terminal run with 256 colors, but a different terminal emulator that doesn't support 256 colors to continue setting TERM=xterm . | * Why is it better to add a script to /etc/profiles.d than to patch specific terminal emulators to set TERM to a 256-color version? This would allow e.g. gnome-terminal run with 256 colors, but a different terminal emulator that doesn't support 256 colors to continue setting TERM=xterm . | ||
--[[User:Mitr|Mitr]] 16:41, 25 June 2012 (UTC) | --[[User:Mitr|Mitr]] 16:41, 25 June 2012 (UTC) | ||
--------------------------------- | |||
Fair enough on remote logins. For xterms logging into Fedora I suppose we should be conservative and not set 256 colors. | |||
I've amended the /etc/profile.d/256color.sh script to do this (in a hackish sort of a way using `who`). | |||
Serial consoles etc. wouldn't have been affected as we keyed on "xterm" et. al. | |||
For ssh logins to remote systems, there is nothing new here really. | |||
One always has to set the TERM to something supported on remote systems. | |||
The issue might be noticed more often given xterm-256color will be set on the | |||
remote system by ssh, so a note as previously suggested will probably suffice. | |||
The "failure mode" in this case is reduced terminal capabilities, down | |||
to what ever the remote system falls back to. | |||
The downside of patching specific terminal emulators to set TERM, is that | |||
it's not a central config point for this generic feature. | |||
I don't know of any terminal emulators in Fedora that don't support 256 colors. | |||
Revision as of 22:11, 25 June 2012
This feature page needs to explain better how the feature will affect remote logins.
What does "degraded experience" mean? Will I simply get the same colors on the remote system that I get now, or will I lose a lot of other features?
If I SSH to a system that doesn't support 256 colors, sometimes from an X terminal, sometimes from a Linux virtual console, and maybe sometimes from Screen or some other kind of terminal, how can I set things up once and for all so that it works right in all cases? Is it enough to set TERM=xterm in all cases?
What if I SSH to a Fedora box from a system that supports only eight colors, or even just black and white?
Does the feature affect serial consoles, Telnet, Kermit et cetera in any way?
Rombobeorn 15:09, 25 June 2012 (UTC)
- SSH is the major downside of this. There should be a way to "unbreak" systems automatically (ideally by editing ~/.ssh/config, or, in the worst case setting up a shell alias), and it should be documented in the release notes.
- Why is it better to add a script to /etc/profiles.d than to patch specific terminal emulators to set TERM to a 256-color version? This would allow e.g. gnome-terminal run with 256 colors, but a different terminal emulator that doesn't support 256 colors to continue setting TERM=xterm .
--Mitr 16:41, 25 June 2012 (UTC)
Fair enough on remote logins. For xterms logging into Fedora I suppose we should be conservative and not set 256 colors.
I've amended the /etc/profile.d/256color.sh script to do this (in a hackish sort of a way using who).
Serial consoles etc. wouldn't have been affected as we keyed on "xterm" et. al.
For ssh logins to remote systems, there is nothing new here really. One always has to set the TERM to something supported on remote systems. The issue might be noticed more often given xterm-256color will be set on the remote system by ssh, so a note as previously suggested will probably suffice. The "failure mode" in this case is reduced terminal capabilities, down to what ever the remote system falls back to.
The downside of patching specific terminal emulators to set TERM, is that it's not a central config point for this generic feature. I don't know of any terminal emulators in Fedora that don't support 256 colors.