Bug 72571 - Undefined TERM causes rcp to fail
Undefined TERM causes rcp to fail
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rsh (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-25 14:29 EDT by arch harris
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-20 05:26:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description arch harris 2002-08-25 14:29:38 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):


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:
Comment 1 Bernhard Rosenkraenzer 2002-08-29 19:48:42 EDT
rcp shouldn't rely on the (nonstandard) fact that some shells set TERM
Comment 2 arch harris 2002-09-01 15:20:47 EDT
I do not disagree with the comment made by bero@redhat.com. The bug may not
be bash's.  But it is a bug in one of the program's involved and hopefully
will be addressed.
Comment 3 Mark Bober 2002-09-20 10:14:26 EDT
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.

Comment 4 arch harris 2002-09-21 17:17:17 EDT
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.
Comment 5 Radek Vokal 2004-09-20 05:26:21 EDT
Only rlogin is using getenv("TERM") and sets it to network if empty. 

Note You need to log in before you can comment on or make changes to this bug.