Sven Joachim - 13.07.17, 11:41: > > Ideally I think screen would recognize that the remote machine doesn´t > > have the terminal description and try from fallback terminal (i.e. > > "screen-256color" which appears to work nice on all Debian 8, CentOS 7, > > SLES 12). Like: > > > > fallbackterm screen-256color screen > > > > But that would be an upstream feature request and I am not sure whether it > > is reasonably possible to implement it. If so, I am willing to create > > one. > It is not possible at all because screen cannot even notice that you're > intending to connect to a remote machine, much less read that machine's > terminal database. Only programs on the remote machine can notice that > there's no terminal entry for your $TERM, and since they have no clue > what terminal emulator you use, they cannot provide a fallback either > (except "dumb" perhaps, which is not too useful).
Okay. Then I´d say say the best thing would be to recommend to use "term screen256-color" in /etc/screenrc until every distro out there has those "screen.something-256color" definitions. I basically understand what screen upstream developers are trying to achieve here: 1. Screen seems to need a different terminal definition than for example xterm or Konsole. Unlike tmux, but see below. 2. Screen used "screen" for a long time. 3. To support 256 colors screen would need to use a different terminal definition. 4. Instead of just using "screen-256color" it tries to accomodate for special terminal emulator needs by trying whether "screen.something-256color" exists locally. Now my question would be: Do current terminal emulators like xterm or Konsole really have special needs? My Konsole doesn´t even use "konsole-256color". Okay, further testing ahead: === Konsole === - TERM="xterm-256color" aptitude => Ok - TERM="konsole-256color" aptitude => Ok - TERM="screen-256color" aptitude => Ok - TERM="tmux-256color" aptitude => Ok === GNU screen === - TERM="xterm-256color" aptitude => Broken, background color missing in empty areas - TERM="konsole-256color" aptitude => Broken, background color missing in empty areas - TERM="screen-256color" aptitude => Ok - TERM="tmux-256color" aptitude => Ok === tmux === - TERM="xterm-256color" aptitude => Ok - TERM="konsole-256color" aptitude => Ok - TERM="screen-256color" aptitude => Ok - TERM="tmux-256color" aptitude => Ok Can´t we just have *that* for screen as well? BTW: - TERM=screen tmux => screen - TERM=screen-256color tmux => screen - TERM=xterm-256color tmux => screen - TERM=konsole-256-color tmux => screen Option "-2" forces tmux to assume it has 256 colors. So lets see: - TERM=screen tmux => screen - TERM=screen-256color tmux => screen - TERM=xterm-256color tmux => screen - TERM=konsole-256-color tmux => screen *Seriously* there *are* different oppinions there on how to handle these things. === xterm === - TERM="xterm-256color" aptitude => Ok - TERM="konsole-256color" aptitude => Ok - TERM="screen-256color" aptitude => Ok - TERM="tmux-256color" aptitude => Ok Conclusion: Only screen seems to need special "screen" like terminal definitions. The others don´t care. Didn´t test any libvte pased terminal so far. Can´t we just have all terminals have UTF-8 with 256 colors and get rid of these terminal definitions :). I have seen more about the behavior of terminal emulations than I ever wanted to know now. Thanks, Martin
signature.asc
Description: This is a digitally signed message part.
