I created a link in Nautilus in the ~/bin directory for a bash script located there. Then I cut and pasted the link into the ~/Desktop directory.

When I click on it nothing appears on the screen. If I right click on the link and select Run nothing appears either. But I know it is running because conky shows multiple CPUs having high load. Normal CPU% should be 5% to 8% but it is hovering around 79%. Each instance of the link is taking about 5% CPU plus systemd is taking 5% CPU for journaling. The temperature is normally < 50C but in this case it hovers around 75C.

I rifled through journalctl and found the offending / looping problem:

$ journalctl -b-1 | grep 'TERM environment variable not set.' | wc
  35763  357630 3325959

I checked the soft link and it appears ok:

lrwxrwxrwx  1 rick rick     30 Mar 26 10:14 Link to grub-display.sh -> /home/rick/bin/grub-display.sh*

Note this is a brand-new script I just posted today: How to display grub menu and options without booting?. Within the script the clear command is used which is linked to TERM error messages in another thread here and here: How can I fix the "TERM environment variable not set" warning in eclipse

Some of the solutions to the journalctl error message above require looking at:

$ env | grep TERM

I'm wondering if this is something ~/.bashrc does when you open a terminal but missing when a desktop shortcut (link) runs a terminal command directly?

The grub-display.sh bash script runs perfectly fine from a terminal window.

How can I fix this malfunctioning Desktop link Nautilus created for me?

2 Answers 2


The problem is the script relies on the TERM environmental variable being setup. The Ubuntu Unity Desktop does not have this initialized when scripts are called. If you open a terminal with Ctrl+Alt+T the variable is setup.

To test your system create a little script called test-term.sh and make it look like this:


#See if $TERM has been set when called from Desktop shortcut

echo TERM environment variable: $TERM > ~/Downloads/test-term.txt
echo "Using env | grep TERM output below:" >> ~/Downloads/test-term.txt
env | grep TERM >> ~/Downloads/test-term.txt

exit 0

Create a link in Nautilus to test-term.sh and run the link. Then check the output file:

$ cat ~/Downloads/test-term.txt

TERM environment variable: dumb
Using env | grep TERM output below:
(... blank line appears here ...)

As you can see the environment variable TERM is blank when the command env | grep TERM is used. Also the variable $TERM is set to dumb which doesn't suit the color-based, mouse-supported command dialog very well.

Boilerplate solution

The short term solution was to include boilerplate code at the top of the two scripts in question:

# $TERM variable may be missing when called via desktop shortcut
CurrentTERM=$(env | grep TERM)
if [[ $CurrentTERM == "" ]] ; then
    notify-send --urgency=critical "$0 cannot be run from GUI without TERM environment variable."
    exit 1
  • While the answer is correct that TERM is the problem, it's usually only set by terminal emulators and console programs. You shouldn't set it to something; having to set TERM manually is an indication that something else is incorrectly configured. Though it is frequently done, for example, to enable 256 color output in common terminals.
    – muru
    Mar 26, 2018 at 23:58
  • @muru Yes I quickly discovered that from subsequent readings. Instead I modified the script with notify-send message to Desktop that TERM is missing. I'll update the source scripts shortly. Mar 27, 2018 at 0:01
  • I think you can work around that problem, if you put something like the following into your Exec line in the desktop file: xterm -e /path-to/your-script. Of course, this assumes that xterm is installed. You can add options to get better graphics, for example xterm -fa default -fs 13 -e /path-to/your-script
    – sudodus
    Mar 27, 2018 at 6:44

The "solution" is not to run programs outside their required environment repeatedly without checking their exit status. dialog, whiptail, etc. are meant for terminals, so they of course require the TERM to be set. So you should run those scripts in a terminal. The same thing would have happened to your "advanced" zenity, yad, etc. if run without an X11/Wayland display.

In your script, you check the output of dialog whilst redirecting error output with normal output. So when dialog "crashes and burns" and prints an error message, you then compare the error output in your if conditions! Why would you do that?


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .