[gentoo-dev] Re: Fixing the TERM mess

[Joe Wells]

Ciaran McCreesh <ciaranm <at> gentoo.org> writes:

> Now, there's a slight problem. If you have TERM=shinynewterm, and
> you ssh to a box with an old terminfo database, you'll get a warning
> or error that your terminal isn't recognised when you try to use an
> ncurses-based application. You can either ask the sysadmin to
> upgrade, or you can install the relevant terminfo files into
> ~/.terminfo. This isn't a major problem, but the local terminfo
> thing isn't very well known, so some people have this silly
> misconception that you're either screwed or have to export a fake
> TERM if the box you're on doesn't recognise your terminal.

The best solution to this that I can think of is to extend OpenSSH
with the capability to copy terminfo information to ~/.terminfo on the
remote system.

This solution would have these advantages:

* The actual TERM name "xterm" or "gnome" or "rxvt" would no longer
  matter at all.  Applications could lie all they like and we would
  not be bothered.  All that is necessary is that on your home system
  things would be set up so that the TERM value determines the right
  information in the local terminfo database or your own ~/.terminfo.
  When OpenSSH copies the information to the remote system, it would
  check in the remote terminfo information (both the system database
  and your ~/.terminfo) for an exact match on the specifications and
  if so reuse the name with the matching data; otherwise it would pick
  a fresh name following a specific convention (e.g.,
  "xterm-via-ssh-3" where "-via-ssh-3" is added just to be different)
  and insert the data in your remote ~/.terminfo.

* The correct information would always be available.  No terminal
  application would ever have to be used with crippled specifications.

* When terminal applications start up, they could choose their own
  name (and bump it with each revision that adds features or removes
  bugs) and ensure that the correct information was stored in
  ~/.terminfo.  This would avoid the problem of stale information in
  the terminfo database.  (Well, some cruft would accumulated in the
  personal ~/.terminfo area, but the entire directory could safely be
  deleted whenever you have no programs running on the system, e.g.,
  at boot time.)

* The terminfo database could eventually no longer matter.  It would
  be needed only for legacy terminal applications that don't supply
  their own information and for terminal applications whose authors
  supply the wrong information (and in both cases the information
  would only be needed on the system the application starts on,
  because OpenSSH would copy the correct values to where they were
  needed).

* The extension to OpenSSH seems not too hard to implement.  OpenSSH
  can run "infocmp" to get a terminfo description as a big string.
  OpenSSH already has support (at least in SSH protocol version 2) for
  copying the values of some environment variables like TERM, so it
  could just reuse this same mechanism to copy the data to the remote
  system.  On the remote machine, "tic" can be used to insert the
  terminfo description into ~/.terminfo.

* Only the OpenSSH package needs to be modified.  Although the various
  terminal applications would benefit from installing accurate
  self-descriptions in ~/terminfo when they start up, this is not
  needed.

* The solution is 100% backward compatible.  Existing usage remains
  exactly the same.  No programs have to be changed other than
  OpenSSH.  Old versions of OpenSSH would still work just as they do
  now; they would just be missing the new advantage.

* If OpenSSH fails in copying the terminfo data into ~/.terminfo on
  the remote system, it can fall back to the old approach just by
  stripping off any "-via-ssh-*" suffix from the TERM value.  (This
  means the convention for picking fresh names needs to be
  reversible.)

* The solution would be automatically deployed worldwide through the
  regular updating of OpenSSH.  People will tend to update OpenSSH
  more quickly than other packages due to the desire to keep their
  security up-to-date.  Anyway, this solution would be another
  motivation for everyone to stay upgraded to the latest version of
  OpenSSH, which is always a good thing.

* Maybe some more people would dump proprietary SSH if they don't add
  the feature quickly enough.  :-)

-- 
Joe Wells

P.S.  I don't normally read this forum at all, so if you want me to
see any replies please e-mail a copy to me.


-- 
gentoo-dev@g.o mailing list