what does "export TERM=linux" actually do when inside a script

Question

My bash script runs extra noisy when run inside a server via ssh.

+ sudo apt-get install -yqq nodejs
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:

One of the suggestion I saw posted out there was doing export TERM=linux

Are there any side affects? Is it a good idea to do at the beginning of the script, like this:

#!/bin/bash
set -e
set -x
TERM=linux

Solution 1

The export TERM=linux command sets the terminal emulator to linux. Depending on the environment and capability of the console you're using, some emulations will work better than others.

The default TERM setting for Ubuntu is xterm. You can check your TERM setting by running echo $TERM.

You may have to check with the provider of the application that you are running to find out the best-recommended terminal emulator for their program. Most application will expect that you already have the emulator set to something compatible such as xterm or linux.

set -x
A debugging setting:
You refer to a noisy script. You're getting verbose output from your script because of the set -x settings which are used for debugging. Once you see what is happening and have your script running the way you want it, you could comment out the set -x line by placing the # symbol in front of it.

set -e
This setting is telling the script to exit on a command error. For instance, if your command was to change directory to a none existing directory or to list a non-existing file, the script would terminate on the error, rather than proceeding to the next line.

Your problem with the ssh via the server you are logging into may result in that, by default the server tries to match the terminal emulator of the settings from the computer you are logging in from. If it doesn't have a match, it doesn't know which settings you can handle. For this, you'll have to use the export TERM command to specify to the server how to communicate with you.

Solution 2

There's no point to setting TERM if a TTY is not allocated. If you're using SSH, use ssh -t:

 -t      Force pseudo-tty allocation.  This can be used to execute
         arbitrary screen-based programs on a remote machine, which can be
         very useful, e.g. when implementing menu services.  Multiple -t
         options force tty allocation, even if ssh has no local tty.

Note these errors:

debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
...
debconf: (This frontend requires a controlling tty.)

Comments

[american-ninja-warrior]

the set commands were not asked about

[Apologician]

I was referring to your reference Are there any side affects? Is it a good idea to do at the beginning of the script, like this:. When you said like this, you put the three lines. I described their usage so that you could consider the intentions of them in a script. Your reference to busy for your scripts sounded as if you were using the set -x option. I wasn't sure if it were your script or a script that came with a package that you were trying to optimize, but not break.