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

A possible solution for odd Terminal behaviors UNIX
I have forever had problems with the Terminal not acting as it should. For instance, the Home and End keys did not do what I expected them to. Well, I finally found out how to get everything working perfectly. Just open a Terminal and type:
export TERM=linux
It works for Terminal, it works when I'm ssh'ed into Linux, it works when I'm ssh'ed into FreeBSD, it works in Postgres psql. It just works. Finally a solution.

Edit your .bash_profile and add the above command, and it will stick whenever you need it.

[robg adds: I haven't tested this one beyond making sure that it didn't break anything. Terminal seems to work fairly well for me in VT100 mode, set via the Terminal -> Preferences dialog.]
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[7,659 views]  

A possible solution for odd Terminal behaviors | 12 comments | Create New Account
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: googoo on Nov 03, '04 09:50:43AM

I use xterm-color as my terminal type when using Terminal.app, and my navigation keys seem to work fine! As far as I can tell the Page Up/Down, Home, and End navigation keys just control the scollbar in the terminal window. Am I missing something?

-Mark



[ Reply to This | # ]
This hint didn't work for me
Authored by: steresi on Nov 03, '04 11:05:31AM

I've tried adding the line "export TERM=linux" into .bash_profile in my home directory. I opened a new terminal window and the Home and End keys didn't move to the start or end of the line. (I did make sure that .bash_profile was executing at login by adding the line "echo 'hello'".)



[ Reply to This | # ]
This hint didn't work for me
Authored by: adrianm on Nov 03, '04 02:25:13PM

Setting the TERM variable has no effect on Terminal's handling of END/HOME/PGUP/PGDN etc as by default, Terminal scrolls around the buffer.

This behaviour is changed in Windows Settings, keyboard tab.

I suspect the poster had already modified that but neglected to mention it.



[ Reply to This | # ]
A possible solution for odd Terminal behaviors
Authored by: durin on Nov 03, '04 12:45:05PM

I've had really good luck using rxvt for the terminal setting...and you can set this in the Terminal program's window settings...

---
Go not to the elves for council, they will say both no and yes



[ Reply to This | # ]
OT - A possible solution for odd Terminal behaviors
Authored by: webbix on Nov 03, '04 12:57:53PM
Slightly off topic but maybe someone can point me to the right place. I am still using tcsh for my shell as I can not get my alias entries in the correct format. I have made a '.bash_profile' (I think I duplicated my tcsh file) and also '.bashrc' to include additional paths. However, when I try to set my default shell to bash I get errors see below). I have looked for info in my unix books and online and can not find anything that shows the difference even when the topic is discussed specifically.
After editing my original this is what I have. It yields errors on launch asking for the type of terminal

Welcome to Darwin!
You have mail.
tset: can't initialize terminal type !* (error -1)
Terminal type? 
I type in xterm to just see what I can get

-bash: export: `cat -n | tail -1 | awk '{print $1}')': not a valid identifier
-bash: alias: print: not found
-bash: alias: $2: not found
-bash: alias: }: not found
This is what I edited to; would have to get my original from home BU

# added 1223.2002 to allow use of alias
# source /Users/user/.aliases

# added a source to 'rc' for my alias file in home directory
# '.aliases' 09.25.2002
# setenv PATH /usr/local/bin:$PATH

export PATH=$PATH:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/local/bin

# enable access to mysql; 07-07-2003

export PATH=$PATH:/Library/MySQL/bin"

##
# TCSH Expanded C-Shell INITIALIZATION FILE
# Aliases file
#
# Wilfredo Sanchez Jr. | tritan@mit.edu
# June 10, 1994
#
# MIT Project Athena
##
alias . ='pwd'
alias ..= 'cd ..'
alias cd..='cd ..'
alias cdwd='cd `pwd`'
alias cwd ='echo $cwd'
alias files='find \!:1 -type f -print'      # files x => list files in x
alias ff='find . -name \!:1 -print'      # ff x => find file named x
alias line='sed -n '''\!:1 p''' \!:2'    # line 5 file => show line 5 of file
alias l='ls -lg'
alias ll='ls -lag \!* | more'
alias term='set noglob; unsetenv TERMCAP; eval `tset -s -I -Q - \!*`'
alias word='grep \!* /usr/share/dict/web2' # Grep thru dictionary
alias wordcount='(cat \!* | tr -s '''  .,;:?\!()[]"''' '''\012''' |' \
                'cat -n | tail -1 | awk '''{print $1}''')' # Histogram words
##
# My aliases are listed below
#
#
# 
##

# showalias: to remind yourself of an alias (given some part of it)
alias showalias='grep \!$ ~/.aliases'

# addaliasitem: to add more alias entries
alias addaliasitem='pico ~/.aliases'

# mylsof: lsof command to show open ports
alias mylsof='sudo lsof -u user -u root | grep TCP | sort +2'

# from OSXFAQ site to search for strings in text files
alias ftxt='find . -name "*.txt" -exec grep -il \!:1 {} \;'

# easy ssh connect to server afp
alias sshano='ssh user@1.1.1.2'  

# launch darkstat from non-standard location?
alias darkst='sudo /usr/local/sbin/darkstat --detach'
  
# kill darkstat
alias kdark='sudo kill `cat darkstat.pid`'

# launch ntop as daemon on 6160
#alias webntop='ntop -d -w 6160'

# ls with color for /bin/ls2
alias ls2='/bin/ls2 --color -axl'

# today in history script
alias 2day='cat /usr/share/calendar/* | grep `date +"%m/%d"`'

# ssh connection through host to main file server
alias afpssh='sudo ssh -C -L 55548:1.1.1.1:548 user@1.1.1.1'
  
# homeland security threat level
alias hstl='echo -n "Threat Level: ";'" curl -s http://www.dhs.gov/dhspublic/getAdvisoryCondition | tail -n 1 | awk -F\"'"'" '{ print "\$2" }''
 
# TOP without memory reporting to reduce CPU load
alias ttop='top -ocpu -R -F -s 2 -n30'

Any pointers?

[ Reply to This | # ]
OT - A possible solution for odd Terminal behaviors
Authored by: thrig on Nov 03, '04 02:17:10PM

bash and tcsh are very different; to debug, perhaps run 'bash -x' or 'bash --verbose' to see what might be going wrong?



[ Reply to This | # ]
OT - A possible solution for odd Terminal behaviors
Authored by: n8gray on Nov 03, '04 03:25:36PM

alias . ='pwd'
alias ..= 'cd ..'
These are broken. You can't put spaces around the = in alias lines. You have to use:

alias .='pwd'
alias ..='cd ..'
Also, aliases can't take arguments in bash so this won't work:

alias files='find !:1 -type f -print'
Instead use a function:

files () { find $1 -type f -print; }
Be sure to leave a space after the { and put a semicolon after the command. You can also use a multi-line syntax for longer functions:

files () { 
   find $1 -type f -print
   echo "hello world"
}
In this case semicolons aren't necessary since the commands are on individual lines.

Hope this helped.

[ Reply to This | # ]

OT - A possible solution for odd Terminal behaviors
Authored by: webbix on Nov 03, '04 04:31:12PM

Thanks, exactly what I needed.

Hated to lose the functionality I had but did not know enough about it and have wanted to give bash a try since 10.3 came out. I will edit my config and give it a try.



[ Reply to This | # ]
OT - A possible solution for odd Terminal behaviors
Authored by: kholburn on Nov 03, '04 05:17:22PM

If you want to check a bash script (which is what this is) you can always run it like this:

bash -x script

or even this

bash -vx script

This will show what bash does for each line



[ Reply to This | # ]
A possible solution for odd Terminal behaviors
Authored by: adrianm on Nov 03, '04 02:21:04PM

Can you elaborate on what you mean by working perfectly and doing what you expect it to do?

Your expectations are likely different from everyone else.

For me, Terminal.app, out of the box, does exactly what I expect it to do, although I sometimes wish it did things differently, in which case I change settings to fit....



[ Reply to This | # ]
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 | # ]