Bug 79512 - ssh's -n flag has no effect
Summary: ssh's -n flag has no effect
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: openssh
Version: 2.1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-12 15:51 UTC by Johan Walles
Modified: 2007-11-30 22:06 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-02-04 10:48:50 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Johan Walles 2002-12-12 15:51:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130

Description of problem:
It seems as if the -n flag has no effect.  Doing...

ssh foo cat /etc/redhat-release

... works fine, but if I do...

cat|ssh foo cat /etc/redhat-release

... I don't get my prompt back after finding out foo's RH version.  To work
around this, I tried the -n flag, which is supposed to "Redirect input from
/dev/null." according to "ssh --help".  However, doing...

cat|ssh -n foo cat /etc/redhat-release

... has the same problem.  The reason I thought it would help to "Redirect input
from /dev/null." was that this works fine as well:

cat /dev/null|ssh foo cat /etc/redhat-release

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. cat|ssh -n foo cat /etc/redhat-release

Actual Results:  I get to see foo's Redhat version string, but I don't get my
prompt back after that.

Expected Results:  I should have gotten to see foo's Redhat version string, and
gotten my prompt back afterwards.

Additional info:

Comment 1 Johan Walles 2002-12-13 15:21:49 UTC
I'm starting to get the feeling that the reason is not ssh, but that cat wants
stdin to EOF before I get my prompt back.  If this is really what's going on
here this should be NOTABUG, but I still want a second opinion on it (even if
that opinion is NOTABUG :-).

Comment 2 Tomas Mraz 2005-02-04 10:48:50 UTC
Re comment #1 - of course :-)

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