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

[P_F]

During an ssh batchmode ssh session I encounter this message which I've been unable to suppress which is sent only to the session screen:

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

This is one example of the command, variants attempted:

ssh -q -o "BatchMode yes" $HOSTNAME ls | grep $STRING > /dev/null 2>&1)


The message string only appears on few nodes - and always the same nodes - out of a 100 or so. I cannot alter any settings on these nodes I am establishing the SSH connection to. I would just like to suppress the message.

Any suggestions ?

[Matti_Kurkela · Accepted solution]

A SSH command line that specifies a remote command will normally run in "non-interactive mode". One of the consequences is that no pseudo-TTY will be assigned for the connection in the remote host.

This happens because /etc/profile, ~/.profile or some other login script on those nodes contains a tput command that is executed unconditionally - even if the session does not have a TTY associated with it. (The HP-UX default login scripts have had this issue for ages.)

The true fix would be to find the tput commands on those nodes and make them conditional. For example, on sh, ksh, bash and other Bourne-style shells, you could replace the command:

tput

with:

tty -s && tput

This will run the tput command only if the session is interactive and has a TTY assigned. ("tput" is a terminal initialization/configuration command, so running it when there is no TTY makes no sense anyway.)

If you cannot modify the login scripts on the remote nodes, a workaround is to tell SSH to request a TTY even if the session will be non-interactive: add the option "-t" to the ssh command line. For example:

ssh -tq -o "BatchMode yes" ...

If you run this command from crontab or some other non-interactive context, there won't be a local TTY either. In that case, you will need "-tt" instead of "-t" to implement the workaround:

ssh -ttq -o "BatchMode yes" ...

MK

[P_F]

Your diagnosis is entirely correct. The remote host's bashrc does in fact contain code as you describe. I put in "t" switch and it worked without receiving the unwanted message.

Thanks.

[P_F]

Question was answered fully.