SCO 5.0.5 (i686-pc-sco3.2v5.0.5), scp and the -n option

[Aran Cox]

Ok, using openssh-SNAP-20010126.tar.gz, two versions of the server both compiled with the
configure commands as below, one with USE_PIPES defined
and one without.  This is on SCO OpenServer 5.0.5 (using SCO dev
environment, SCO make, etc.)  The client is always linux, openssh
2.3.0p1.

export CCFLAGS='-L/usr/local/lib -I/usr/local/include'
./configure --sysconfdir=/etc/ssh --with-rsh=/usr/bin/rcmd \
--exec-prefix=/usr --without-egd-pool

Host: i686-pc-sco3.2v5.0.5

I used two versions of a simple shell script to invoke ssh and scp
repeatedly, the first does not specify the -n option to ssh, and
second version uses -n on all the ssh invocations. 

The commands:
ls -ld .
ssh -V
'cat /etc/hosts|grep localhost'
scp /etc/hosts root@$host:/tmp/hosts.foo
/usr/bin/X11/xterm -sb -sl 1000 -T $host -e '/tmp/test-scr.sh'

(The /tmp/test-scr.sh script just runs find /etc and sleeps for 2
seconds.) 

Now, on the machine without USE_PIPES (that is the unmodified snap
20010126) the non -n script runs just fine repeatedly... except that
although execution of the script continues past the invocation of scp,
scp doesn't exit, they just pile up on the client side. The sshd
for scp doesn't exit either until you kill ssh on the client side. 

When the non -n script is run against a server with USE_PIPES,
everything seems to run just fine, scp exits and leaves no residue.

Now, if I run the -n version of the script,

On the server without USE_PIPES, every command invoked hangs and the
script won't continue executing unless you kill the corresponding sshd
or ssh process.  Sometimes it hangs before I get my input back,
sometimes not.  Strangely, I seem to only get input back from ssh -V,
and not ls or the cat|grep command.  scp does copy the file as
expected. (scp behaves as above to this server) The xterm does appear,
and close, but the sshd still hangs around along with the ssh.

If I try the -n version of the script on the USE_PIPES server,
everything works absolutely fine.  

Essentially I've reported these same type of problems in August, but
now the command hangs instead of dying with a  
Disconnecting: Command terminated on signal 13.
error message.  (USE_PIPES fixed it for me then, too.)

The real question (for me) here is in what circumstances do I need to
use -n?  I would swear that in the past, I have needed -n to keep
shell scripts from hanging on invocations of rsh/rcmd.  Now, I can't
duplicate that to save me. (Either with rsh/rcmd or ssh.)  It appears
that I don't even need -n to get X applications to work correctly.  If
it weren't for the problems with scp hanging around I would just drop
the -n and forget about USE_PIPE entirely, but -n ought to
work. However, since I can't seem to find a concrete use for the
option, that point may be moot. 

I would really like to see if anyone can duplicate this. Alternately you
could just take my word for it and put USE_PIPES back into the
configure.in script for *-*-sco3.2v5* ;)

Aran