Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recently started receiving the following error when running commands directly through the ssh command:

tput: No value for $TERM and no -T specified

The command I'm running from one linux box (we'll refer to as alpha) to box beta to produce the error is:

[dtbarne@alpha ~]$ ssh beta ls

Everything seems to work fine, I just get 33 lines of the aforementioned error. If I try running the same command to another server, like [dtbarne@alpha ~]$ ssh charlie ls, I do not see the error, so it seems to be isolated to beta.

However, if I jump into a session with just [dtbarne@alpha ~]$ ssh beta and then run ls, I never see the errors.

share|improve this question
up vote 7 down vote accepted

Most probably there's a tput command in the user's .bashrc on beta, and it doesn't bother to check whether the shell is interactive. This will not only break ssh but also various programs that invoke the shell for filename expansion (file names with wildcards in vi/nvi/vim, Perl's <*> glob operator, etc.).

With Bourne/POSIX-compatible shells you're supposed to either test for the i flag in $- or test for $PS1 being nonempty (the former being the official way); with csh/tcsh you test $?prompt.

share|improve this answer
Ok, so I guess I suspect this line in my .bashrc to be the culprit: export PS1='\[$LightGreen\][\t] [\u@\H \W]\$ \[$NC\]'. Added this recently, but now it seems when I comment the line out, I gett the same error lines, but they now display after the command output rather than before. – dtbarne Jul 6 '11 at 4:40
My suspicion, from seeing that, is that it's the lines where you set $LightGreen and possibly $NC that actually produce the error. Also, don't set $PS1 if it isn't interactive. – geekosaur Jul 6 '11 at 4:42
You suspect correctly. I'm D'ohing about now. That is indeed the problem. Thanks a ton for your help! – dtbarne Jul 6 '11 at 4:55
Got it working properly with: – dtbarne Jul 6 '11 at 5:03

Try with

ssh -t host ls


env TERM=xterm ssh host ls

Try to redirect the error stream with your shell, if you still see the error messages this means it comes from the remote server. If not, it comes from your client. Termcaps errors occurs mostly when the environment variable "TERM" is not properly set.

share|improve this answer
Thanks for taking the time to help. The first solution sort of works. No errors, but the output is formatted different and it appends a closed connection message. The second solution unfortunately doesn't work at all. Regardless, I'm looking to fix the source of the problem rather than work around it. – dtbarne Jul 6 '11 at 4:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.