23

I recently upgraded (with apt-get dist-upgrade) my Kubuntu and Lubuntu Linux boxes, and now every time I log into one of these machines, I get this message:

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

Here is a screenshot of the exact message: tput: No value for $TERM and no -T specified

This happened on both my Lubuntu machine and Kubuntu machine, and it wasn't a problem until after I upgraded; so I suspect that it was not user error.

How can I fix this?

UPDATE

I have tracked this down to my .bashrc file, which is getting called by my .profile file. Though, the fact that my .bashrc file now runs when I do a GUI login whereas it didn't before I upgraded is a bit weird. And no, I haven't modified my .bashrc file or my .profile recently. Also, bash isn't my default shell.

The problem is that I am calling tput in my .bashrc file to set up variables for use in adding color to the prompt. But at the (inappropriate) time when my .bashrc file now gets run, $TERM is not set.

fgRed=$(tput setaf 1)     ; fgGreen=$(tput setaf 2)  ; fgBlue=$(tput setaf 4)
fgMagenta=$(tput setaf 5) ; fgYellow=$(tput setaf 3) ; fgCyan=$(tput setaf 6)
fgWhite=$(tput setaf 7)   ; fgBlack=$(tput setaf 0)
bgRed=$(tput setab 1)     ; bgGreen=$(tput setab 2)  ; bgBlue=$(tput setab 4)
bgMagenta=$(tput setab 5) ; bgYellow=$(tput setab 3) ; bgCyan=$(tput setab 6)
bgWhite=$(tput setab 7)   ; bgBlack=$(tput setab 0)

Updated question: How should I fix this? Should I set $TERM myself? Or should I just not set these variables if $TERM is not set?

UPDATE 2

One solution I tried was to check whether $TERM was set. But this didn't seem to work; I still got the same error message. Here's the code:

if [ ! "$TERM" = "" ]; then
  #Do stuff here
fi

So apparently $TERM was set, but tput still concluded it wasn't.

  • 1
    If I'm not mistaken .profile runs regardless of the default shell – Sergiy Kolodyazhnyy Mar 4 '15 at 20:08
  • @Serg but during a GUI shell login? Also, I didn't always see this problem. – Sildoreth Mar 4 '15 at 20:34
  • Well, yeah, it should be ran upon user loging in and this is exactly what you were doing – Sergiy Kolodyazhnyy Mar 4 '15 at 20:38
14

What ultimately worked for me was to check whether the shell was an interactive shell. I based the solution on this other post at unix.stackexchange: How to check if a shell is login/interactive/batch.

So the code for the solution was:

if [[ $- == *i* ]]; then
  fgRed=$(tput setaf 1)     ; fgGreen=$(tput setaf 2)  ; fgBlue=$(tput setaf 4)
  fgMagenta=$(tput setaf 5) ; fgYellow=$(tput setaf 3) ; fgCyan=$(tput setaf 6)
  fgWhite=$(tput setaf 7)   ; fgBlack=$(tput setaf 0)
  bgRed=$(tput setab 1)     ; bgGreen=$(tput setab 2)  ; bgBlue=$(tput setab 4)
  bgMagenta=$(tput setab 5) ; bgYellow=$(tput setab 3) ; bgCyan=$(tput setab 6)
  bgWhite=$(tput setab 7)   ; bgBlack=$(tput setab 0)
fi
| improve this answer | |
  • Aha, that's an elegant solution. :) – Gunnar Hjalmarsson Mar 4 '15 at 21:08
  • 2
    If this is in .bashrc, I find it surprising. The default .bashrc contains: # If not running interactively, don't do anything case $- in *i*) ;; *) return;;, so your settings shouldn't be applied unless interactive. – muru Mar 4 '15 at 22:41
  • @muru My .bashrc file is very non-default. :) – Sildoreth Mar 5 '15 at 13:59
  • But where did you do that? in .bashrc? – jjmerelo Mar 14 '15 at 16:59
  • I think if you put this at the top of your file it's cleaner: [[ $- == *i* ]] || return Ref: (askubuntu.com/a/1070182/362122) – Klik Jan 9 '19 at 19:00
9

If you do this

if tty -s
then
    : # your tput commands
fi

It will fix your problem. Without the -s option tty will either display your tty or write "not a tty"

| improve this answer | |
  • The description of tty from its manual page is "print the file name of the terminal connected to standard input." If the stdin of your script is a pipe, this test will fail, with the consequence being your program stops printing colors in its output just because its input is coming from a pipe. Maybe test -t 1 (in English: "is stdout connected to a terminal?") is what you really want? That way you get colors only if the output is going to a terminal, and you won't see weird terminal codes if you redirect its output to a file or pipe it through, say, less. – TheDudeAbides Mar 25 '19 at 18:04
7

For me, adding

export TERM=xterm

to /etc/profile was the only thing that solved the problem. Actually, the error gave us a hint: No value for $TERM

| improve this answer | |
4

[Different scenario, but search engine lead me here first]

When "tput: No value for $TERM and no -T specified" error occurs in a Docker container (for me, when opening a zsh shell calling docker exec -it <container> zsh (-i for interactive)) the only way to fix this, was to set the variable like ENV TERM xterm-256color in the Dockerfile for this image.

Approaches like RUN export TERM=xterm-256color or RUN echo "export TERM=xterm-256color" >> ~/.zshrc were not successful. Other values for TERM are also possible.

| improve this answer | |
3

Try opening terminal (doesn't matter which, even tty1 will do) and run this line

sudo update-alternatives --config x-terminal-emulator

You will be presented with choice of the default terminal emulator for x window. Choose one by selecting number, and reboot after you're done.

$ sudo update-alternatives --config x-terminal-emulator
There are 6 choices for the alternative x-terminal-emulator (providing /usr/bin/x-terminal-emulator).

  Selection    Path                             Priority   Status
------------------------------------------------------------
  0            /usr/bin/gnome-terminal.wrapper   40        auto mode
  1            /usr/bin/gnome-terminal.wrapper   40        manual mode
  2            /usr/bin/koi8rxterm               20        manual mode
* 3            /usr/bin/lxterm                   30        manual mode
  4            /usr/bin/sakura                   40        manual mode
  5            /usr/bin/uxterm                   20        manual mode
  6            /usr/bin/xterm                    20        manual mode

Press enter to keep the current choice[*], or type selection number:  
| improve this answer | |
  • When I try this, it tells me "There is only one alternative in link group x-terminal-emulator [...] Nothing to configure". This is on my Kubuntu machine. – Sildoreth Mar 4 '15 at 20:38
  • Try installing another terminal emulator, for instance gnome-terminal or sakura – Sergiy Kolodyazhnyy Mar 4 '15 at 20:41
  • I had exactly the same problem. I have selected sakura. However, this seems to be a problem with the gnome terminal wrapper; if so, why not fix that? – jjmerelo Mar 14 '15 at 8:39
  • It does not fix the problem, actually. – jjmerelo Mar 14 '15 at 16:58
  • 2
    @jjmerelo As OP later revealed in his answer, he had lines in his .bashrc file, which was giving the error. Gnome terminal wrapper shouldn't be the issue. My guess initially was that $TERM variable wasn't set, which is was another user, Gunnar, mentioned in his answer. – Sergiy Kolodyazhnyy Mar 14 '15 at 21:47
1

The error dialog is due to the fix of bug #678421, so it's my fault. ;) It tells you about errors due to some command(s) in one of your configuration files. If you scroll to the top, you can see which file is causing the error messages.

Possibly Serg's answer is sufficient to get rid of the warning dialog.

Edit:

Would like to add a couple of things due to the updated question.

Unlike before, /usr/sbin/lightdm-session is now run under bash (previously sh). That's why its sourcing of ~/.profile results in ~/.profile sourcing ~/.bashrc. Possibly this means that the default contents of ~/.profile ought to be changed.

The easiest thing you can do to fix it is, as you suggested, to only call tput if $TERM is set.

| improve this answer | |
  • I tried checking whether $TERM was set, but it didn't seem to work. – Sildoreth Mar 4 '15 at 21:01
  • @Sildoreth: Can you please show us the exact code for doing so? (Please edit your question again.) – Gunnar Hjalmarsson Mar 4 '15 at 21:05
  • added to question – Sildoreth Mar 4 '15 at 21:09
  • @Sildoreth: Saw it. Maybe it's because tput is called in subprocesses. (Just a guess.) Anyway, you found a nice way to deal with it. – Gunnar Hjalmarsson Mar 4 '15 at 21:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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