Red Hat Bugzilla – Bug 72571
Undefined TERM causes rcp to fail
Last modified: 2007-04-18 12:46:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
Description of problem:
When connecting to a 7.3 system, a rcp client will fail with the message "No
value for $TERM and no -T specified" for users whose shell on the server ssystem
is the bash that comes with 7.3. Apparently, unlike previous versions of bash,
the one in 7.3 does not set TERM to "dumb" and export TERM.
If this is not a bug in bash, then it is a bug in either rcp or in.rshd. Rsh
has a simlar problem but only to the extent that it prints the same error
message. The problem does not prevent the rsh command from executing.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Execute: rcp /tmp/test server:/tmp/test where /tmp/test has been created on a
client system, server is configured to accept rcp connections from the client,
and the user uses /bin/bash on the server for his/her shell.
Actual Results: No cpy occurs and the message "No value for $TERM and no -T
specified" is output.
Expected Results: No error message and the file is copied
rcp shouldn't rely on the (nonstandard) fact that some shells set TERM
I do not disagree with the comment made by firstname.lastname@example.org. The bug may not
be bash's. But it is a bug in one of the program's involved and hopefully
will be addressed.
I have this behavior happen to me on a irregular basis - I've found no way to
reproduce it at will. However, it has never occured when using an rcp - I've had
it come up when connecting via ssh (openssh-3.1p1-6) as root - the "No value for
$TERM and no -T specified" message occurs twice (pointing to the execution of
/etc/bashrc, the 'tputs' to be exact) and TERM is then set to 'dumb'. root's
shell is bash.
It also happens in a commercial package, PBSPro, which in a nutshell executes
jobs through a daemon on a client system as the user whom submits the jobs. It
is irregular here as well. (I do not expect RedHat to worry about a commercial
package not part of their distribution, I just felt it worth reporting, since it
is the same behavior as what happened with OpenSSH) The message is repeated
twice here as well in the job's error stream, again pointing to /etc/bashrc.
If I can find a way to make it happen at will, I will let you know.
I know what the bug is (actually there are 2) but am not sure what entity should
be marked as having the bug. The server system's "rlogind" daemon is supposed
to propagate " the client terminal's baud rate and terminal type." This is not
happening, I do not know if the problem is on the client or the server side (or
both). TERM on the server comes up as "dumb" at the start of
".bashrc" even though the client TERM was "linux". That is bug 1.
The second bug is TERM is not exported (and I would interpret "propagates" in
the "rlogind" documentation to mean "exports"). I would consider this a bug in
"rlogind". If not "rlogind", it is a bug in "bash" or the ".bashrc" files
in /etc/skel (something should be exporting it).
rcp failed in my case because at one point in /etc/bashrc I assigned
the output from a tput command into a variable. Since tput ran in a separate
process, TERM was undefined and an error meesage was produced. Any output
during the execution of the bashrc scripts (stdout or stderr) causes "rcp" to
abort. The bug work around is to add a
[ -z "$TERM" ] && TERM=dumb ; export TERM;
at the beginning of the bashrc sequence.
Only rlogin is using getenv("TERM") and sets it to network if empty.