Bug 72571
| Summary: | Undefined TERM causes rcp to fail | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | arch harris <service> |
| Component: | rsh | Assignee: | Radek Vokál <rvokal> |
| Status: | CLOSED WONTFIX | QA Contact: | Ben Levenson <benl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-20 09:26:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
arch harris
2002-08-25 18:29:38 UTC
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.
|