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


Click here to return to the 'A possible solution for odd Terminal behaviors' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A possible solution for odd Terminal behaviors
Authored by: erikh on Nov 03, '04 06:13:10PM

Terminal.app has issues (I recommend iTerm), but this is not one of them.

The problem is that most of the Linux termcaps have a substandard vt100 entry. You'll find that if your terminal is initiated from FreeBSD (or pretty much anything but linux), you'll have this problem. Slackware routinely is the exception, but Slackware has always had a BSD bent so this is no surprise.

Personally, I've found that using stty to fix a few things works well, but also to use bourne shell keymaps instead of relying on your keys to emulate properly works in almost all scenarios. Example:

set -o vi

Your shell will now operate like 'vi', 'h' and 'a', etc, will work as you would expect them to.

set -o emacs (normally the default, especially for bash)

^E and ^A are end and home, respectively.

These work in all terminals consistently. In fact, they work so well, that you'll swear violently when a program doesn't have proper readline support (in which your characters will be prominently echoed on the terminal). It doesn't take long to get used to, and most other things in all parts of the editing world (even this form in Firefox), do it as well. I remember swearing violently when Netscape mapped ^D to "bookmark", I suddenly had 30 copies of the form I was using to write a comment. :)

I'm certain that at least tcsh has commands to invoke similar behavior.



[ Reply to This | # ]
A possible solution for odd Terminal behaviors
Authored by: geohar on Nov 04, '04 05:05:55AM

Someone got there first!!!

I think terminfos and terminal emulation bear a little explanation - os here goes.

vt100 DEC and other terminals were actual physical pieces of hardware that came with weighty manuals describing the escape sequences they understood and the escape squences various keys generate.

Skip a few years (quite a few).

It becomes a real pain to write software that works on different terminals which use different escape sequences to produce things like bold, position the cursor etc. Enter curses and later ncurses. These libraries abstract the producing of escape sequences so that they work on different terminals. All that is needed is to know what terminal you have....

The TERM variable could be used to guess this. But that would mean each program needed an inbuilt understanding of how to generate escape sequences. Now that's a bad plan. The TERMCAP variable (and database) allowed a program to read a set of capabilities and 'know' how to work for a given terminal. Later terminfo (which is what OSX uses) was created, as a more capable repository of knowledge on how to drive or understand a given terminal.

Meanwhile the decline of physical terminals means you have terminal emulators. These are programs which pretend to be a given terminal type. They emulate the keypress sequences of that terminal and understand a set of escape sequences to control how text appears.

When you set TERM, programs you run, will look up the terminfo entry for that terminal, and use it to generate the escape sequences to control text display. Now one of the things that can go wrong is that the terminfo entry / TERMCAP setting is crappy and incorrect. By incorrect, I mean that the description does not acurately match the physical terminal's manual. This can be the case when logging into some UNIX/Linux boxes. Remember, the terminfo on the box you run the program is what is used. There's always the option to fix it. You use tic tac toe and infocmp to do this (but I'm not going to explain in too much detail as it's pretty complex and deserves a good session with the man pages).

Another thing that can go wrong is that your terminal emulator doesn't really understand everything it should. This means either 1. it doesn't recognize some escape sequences so you get wierd char sequences involing [ etc on your screen. 2. It doesn't generate the correct sequences for keypresses. This second one is far more likely with Terminal.app. See http://www.macosxhints.com/article.php?story=20040401033846410&query=page+up+terminal For how to fix this. I didn't just make these keys up, they're from http://rtfm.etla.org/xterm/ctlseq.html . As you can see, these are the 'correct' keysequences for an xterm / xterm-color.

Why use xterm-color then? Because it has (out of the provided options) the best support for colour and so on. Ok - maybe it's close between rxvt and xterm-color. Whatever. The point is, that you should understand what it means to alter TERM.

Caveats:
Altering the setting in Terminal.app may also alter the set of escape sequences it reconizes. It'll generally be a bad idea to select one TERM in Terminal.app and override it in your startup scripts by setting TERM.

Some programs like VI actually examime TERM to enable things like xterm mouse support (ie, they want the term to be called xterm not just the terminfo to say "I've got mouse (/kmous incase you're interested). This can be fooled in vi by setting ttymouse=xterm. BTW, that's not that useful in Terminal as it doesn't report the mouse anyway!



[ Reply to This | # ]