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): How reproducible: Always 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. 2. 3. 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 Additional info:
rcp shouldn't rely on the (nonstandard) fact that some shells set TERM
I do not disagree with the comment made by bero. 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.