On 2015-08-26 12:05, Axel Beckert wrote:
> Matthew Gabeler-Lee wrote:
>> This isn't just mlterm.  This breaks xterm, xterm-256color, etc. too
>
> I'm sorry, but while I can reproduce the issue with "env TERM=mlterm
> screen", I can't reproduce it with "env TERM=xterm-256color screen"
> (on Jessie). In the latter case, dircolors just look fine to me.

I'm on stretch (testing) personally.  Launching screen inside
gnome-terminal is b0rked because of this for me, or at least it was
until I added logic to my ~/.bashrc to undo these broken TERM values and
push everything back to just being "screen".

>> Some systems don't even think the munged TERM values are "real" and
>> cause problems like less complaining "WARNING: terminal is not fully
>> functional".
>
> That's IMHO a different issue. You should be able to work around it by
> either uninstalling ncurses-term locally or installing it remotely.
> IIRC if screen can't find the according terminfo entries, it won't use
> them and hence won't change $TERM to something more fancy than just
> "screen".

I'm hitting this when using ssh from within a local screen.  I can't
demand that the sysadmins of every old non-Debian system I might want to
SSH to install a potentially unavailable package on their servers.

And if I uninstall ncurses-term on my local system, then trying to
connect to my from inside a screen on another system that does have that
package will be broken.

There needs to somehow be a trade-off here between supporting the newer
terminal features inside the screen session and not breaking access to
older systems.  I doubt the openssh folks would be impressed by an
enhancement request to support conditional expression-based changes to
the TERM variable, not to mention the degenerate case of plain old telnet.

The best compromise I can come up with at the moment is an option to
screen to disable this munging and just use plain old TERM=screen within
a given session.  That (plus the fix to dircolors, which from the other
recent email seems like an independent issue) would be a usable
workaround / compromise for me.  That would be an upstream feature
request I guess...

Reply via email to