Re: Coerce "MATE terminal" to display black on white text?
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.)
Reply to: