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@gentoo.org mailing list
