Re: Coerce "MATE terminal" to display black on white text?

[Greg Wooledge <greg@wooledge.org>]

On Tue, Jun 01, 2021 at 05:04:38PM +0300, Reco wrote:
> On Mon, May 31, 2021 at 09:49:36PM -0400, Greg Wooledge wrote:
> > On Mon, May 31, 2021 at 07:30:42PM -0400, songbird wrote:
> > > Richard Owlett wrote:
> > > > The MATE terminal "Help"(sic) claims VT102 emulation but does not say 
> > > > how to obtain it.
> > > 
> > >   i'd put in my .bashrc the line:
> > > 
> > >   TERM="vt102" && export TERM
> > 
> > That's unwise.  It'll screw you up *hard* any time you're not using
> > the terminal you normally use -- e.g. on ssh logins, or if you want to
> > test another terminal, or if you use tmux or screen, etc.
> 
> In my experience, one will be screwed much more by using TERM=screen or
> TERM=tmux in conjunction with ssh.
> Simply because the ssh target does not necessary have an appropriate
> termcap for screen or tmux (say, Solaris 10 which I have to deal on a
> weekly basis, and yes, I know I can copy termcap entries there).
> And if you think that Linux is somehow better here - try
> TERM=screen-256color in conjunction with RHEL5 :)
> 
> On the other hand, vt102 and xterm - even HP-UX knows about them.

You can install new terminfo entries on your RHEL and HP-UX hosts, for
terminals which you will be using frequently.

On the client (or any system with a matching terminfo entry), use
"infocmp terminalname" to generate the "source code" for a terminfo entry.
Save that to a file on the target, and run "tic filename" to compile it.
If you do this as root, it becomes available system-wide.  If you do it
as yourself, it goes into your HOME directory, and only works for you.

This is probably a better long-term solution to your issues than
intentionally crippling (or full-out breaking) all of your local terminals.

If you don't like that workaround, you can always run "TERM=vt102" or
whatever *on the remote system* after ssh-ing in.  There's no reason to
do it on the client, let alone permanently in .bashrc for every terminal
you open on the client.

If you don't like *that*, you could arrange for your ssh commands to
carry the bogus TERM value, using a shell function or alias.  For example,
in bash:

ssh() {
    case "${!#}" in
	mercury | *@mercury) TERM=vt102 command ssh "$@";;
	venus | *@venus)     TERM=vt220 command ssh "$@";;
	*)                   command ssh "$@";;
    esac
}

This relies on the remote target's hostname being the last argument of
your ssh command, with or without a leading username@ prefix.  Adjust
as needed.

(I am not aware of any method of overriding TERM on a per-host basis
in .ssh/config but if such a method *does* exist, it would be far better
than this shell function hack.)