Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A custom terminfo to restore 10.2 Terminal behavior UNIX
I can't quite remember exactly when this changed, I think most likely during the transition from 10.2 to 10.3, but I'm no longer sure. In any case, Terminal used to behave in a (to me) reasonable manner when using such applications as vi, less and top. These programs and probably others will use the (emulated, e.g., xterm) terminal's "alternate screen buffer" if available while they do their work, and restore the previous screen contents when they exit. The problem is that most of the time, I don't want them to do this. In fact, I want just the opposite, especially if i want to scroll back through that man page I just read, etc.

The Problem:
Back in the 10.2 (?) days, this wasn't an issue -- for whatever reason (my guess being differences in the terminfo database), this alternate screen business was ignored, and one could see the work left behind by exiting programs. With Panther, and its incorporation of significant Linux influences, this behavior changed, much to my disappointment. Suddenly, one-too-many presses of the space bar and man pages were disappearing, pids that top revealed as needing to be killed were no longer visible after hitting "q" -- a whole litany of annoyances cropped up.

A solution:
I have seen various suggestions in various places regarding remedies, but none of them have been optimal. Some fixed the problem, but caused others equally irritating. Finally over Christmas, I found the time to play around a bit, and created an alternate terminfo entry for xterm-color.

What it does:
My slightly altered xterm-color has the following beneficial (at least to me) effects:
  1. Disables the "alternate screen buffer" so the work done by a program is left on the screen after it exits, as described above.
  2. Fixes an annoying problem with some other terminfo entries in which the last line of top's output is overwritten by the shell prompt upon exit.
  3. Allows the use of colorschemes and syntax coloring in vim without drawing insane underlines all over the place.
How it works:
By replacing the xterm-color entry in the terminfo database, we can alter the capabilities which tell programs the character sequences to send to the Terminal to begin and end the use of the alternate screen buffer. If we then tell Terminal to use our new terminfo entry, its xterm-color emulation will take on the behavior specified by the altered entry. In the replaced entry, only the smcup and rmcup capabilities have been changed; it is otherwise exactly the same as Apple's xterm-color which shipped with Panther.

How to install it:
  1. Download the compiled terminfo description file. The source is also included, so if you're paranoid, you can compile it yourself. Doing so isn't that hard, but requires a little work which is beyond the scope of this hint.

  2. In a Terminal window, cd to /usr/share/terminfo, and do a find . -name xterm-color. If your system is the same as mine, you should see this:
    ./78/xterm-color
    If not, replace 78 in the following with whatever directory your xterm-color entry was in.

  3. Make a backup copy prior to replacing:
    $ cd 78
    $ sudo cp xterm-color xterm-color.apple
    Obviously, use whatever name you want for the backup.

  4. Move or copy your downloaded xterm-color (in the archive's compiled directory) into place. You'll probably want to use sudo again, and set the ownership and permissions to correspond with those of the other files in the directory.
Now, if your Terminal preference for "Declare terminal type ($TERM) as" is set to "xterm-color," new windows opened subsequent to the replacement should exhibit the beneficial effects described above. You don't need to restart Terminal.

If you decide you don't like it, just replace the downloaded xterm-color with your backup copy.

Disclaimer:
As you might guess, there are several other ways in which similar effects can be achieved. The one I have decided to implement may be less than optimal depending on your needs or philosophy, but it fits mine. This hint is offered in the hopes that others may find it useful, and does not pretend to be the "best" or even the only solution.

[robg adds: This hint describes (in the hint and comments) a couple of other ways of working around the problem; between these two hints, there should be a solution for everyone. I've personally just set the terminal type to VT100, though that leaves me with the "last line overwrite" problem in top described above...]
    •    
  • Currently 1.50 / 5
  You rated: 2 / 5 (4 votes cast)
 
[11,884 views]  

A custom terminfo to restore 10.2 Terminal behavior | 9 comments | Create New Account
Click here to return to the 'A custom terminfo to restore 10.2 Terminal behavior' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A custom terminfo to restore 10.2 Terminal behavior
Authored by: d1taylor on Dec 29, '04 10:08:34AM
*phew* that's a long, difficult solution. My alternative is to just add
TERM=ansi
to my .bashrc file in my home directory. :-)

[ Reply to This | # ]
A custom terminfo to restore 10.2 Terminal behavior
Authored by: Cap'n Hector on Dec 29, '04 11:05:28AM

TERM=ansi
failed for me…no change in my terminal behavior.

Would there be any way to do this hint without installing into /usr? I have a habit of wiping system directories as part of a re-install, and hate stuff that isn't in ~.



[ Reply to This | # ]
A custom terminfo to restore 10.2 Terminal behavior
Authored by: jpf on Dec 29, '04 12:25:39PM
d1taylor wrote:
*phew* that's a long, difficult solution. My alternative is to just add

TERM=ansi

to my .bashrc file in my home directory. :-)

sorry for the excessive verbosity ... had i chosen to be even more long-winded, you would have been able to read, had you chosen to do so, that TERM=ansi was one of those "less than optimal" solutions. biggest problem with ansi is that it doesn't have decent support for syntax coloring in vim. the other hint robg mentioned in his editorial comment also contains a good deal of interesting information. if i'd found it earlier, i might not have even written my hint, although mine does solve all my problems (which of course may not be yours) ...

in answer to capn hector, there is some evidence that some programs can look for and use a TERMINFO environment variable, or will pay attention to terminfo entries in a ".terminfo" directory in your home directory, but i wasn't able to achieve anything useful by playing around with those things. it seems to me that probably Terminal is not one of those that bothers checking ... i seem to recall scrolling through the output of strings having been run on the Terminal executable, and not seeing anything that would indicate its support for such a feature. unfortunately, we are thus pretty much stuck with having to put stuff in /usr/share/terminfo.

one thing that may help there is to just keep all your custom stuff somewhere under ~/, and then just symlink to that from the "real" locations. at least that way, only the links will get overwritten by system updates and installs, and you won't lose your custom stuff, although you'll of course have to recreate the links.

in another hint/thread somewhere, i have a link to my "checklist" of custom stuff that i have to redo every time a new system dot-release comes out. it's a couple pages long, full of stuff i'd forget to do if i didn't have it written down.

[ Reply to This | # ]

A custom terminfo to restore 10.2 Terminal behavior
Authored by: blm on Dec 29, '04 03:22:29PM

Thanks jpf for the hint. A couple comments on the hint and your followup:

There's no reason to expect Terminal to do anything with terminfo stuff, it's programs started in the Terminal session that use the curses and/or terminfo libraries which use the compiled terminfo files.

~/.terminfo does work for me. You have to duplicate the directory structure, so just putting xterm-color in ~/.terminfo isn't enough, you have to make a 78 directory then put xterm-color in that. Once I do that, I see the new behavior, and if I rename the directory, I see the old behavior.

Setting TERMINFO to the directory path also works for me, so if you want to share the terminfo entry among accounts you can make a directory some shared placed and set TERMINFO in the appropriate place(s).

For those interested, man curses describes all the places compiled terminfo files can be placed. There's a bunch of them, although I suspect ~/.terminfo or TERMINFO are sufficient for most people.



[ Reply to This | # ]
A custom terminfo to restore 10.2 Terminal behavior
Authored by: RiotNrrrd on Dec 29, '04 12:45:12PM
That's probably useless unless you've also gone into Terminal's Preferences and set the Declare terminal type ($TERM) as: pull-down menu entry to ansi as well.

And, as others have noted already, ansi has only a subset of capabilities compared to that menu's xterm-color entry (or rxvt, which is another feature-rich entry).

[ Reply to This | # ]
A custom terminfo to restore 10.2 Terminal behavior
Authored by: megagram on Dec 29, '04 02:29:25PM

It rocks! Best hint ever! Thanks a lot! I've been playing around with every single TERM setting and have never been 100% satisfied. Colours don't display properly, or top, less and other info is wiped from screen etc. Now I am 100% happy.

Thanks for this!



[ Reply to This | # ]
A custom terminfo to restore 10.2 Terminal behavior
Authored by: Thom on Dec 29, '04 06:14:13PM
I wasn't sure what exactly had changed this, because I'd also switched to zsh as my default shell. I also found this quite annoying.

My solution was to set the 'LESS' env var to ='-X'.

From the man page:

       -X or --no-init
              Disables sending the termcap initialization and deinitialization
              strings to the terminal.  This is  sometimes  desirable  if  the
              deinitialization  string does something unnecessary, like clear-
              ing the screen.

Yet another way to skin this cat.

HTH,

Thom

[ Reply to This | # ]

Ack, except last-line overwrite.
Authored by: Thom on Dec 29, '04 06:18:15PM

I should mention that my solution does NOT solve the last-line overwrite issue. It's kind of sad; even when I do little one-liners in perl or php, I have to remember to append a newline to them. (Or, pipe them to less!)

When asked, snooty people told me that all processes should end with a newline at the end of their output anyway. (So harumph, evidently!)

Sigh.



[ Reply to This | # ]
A perfect fix for an annoying problem!
Authored by: excarnate on Apr 22, '08 12:08:42PM
Completely.

Awesome.

I was close to correct by following information from
http://www.cs.utk.edu/~shuford/terminal/ssh_news.txt
but I see it isn't as simple as blanking out the two settings.

This hint for my Macintosh, plus putting "XTerm*titeInhibit: true" in my ~/.Xdefaults on my Unix servers has removed a sharp thorn from my side.

The only thing that would be better would be getting the default terminfo files fixed.

[ Reply to This | # ]