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.)