scp not tolerant of extraneous shell messages

[Bryan Henderson]

>scp is rcp in a ssh wrapper.  and rcp will also fail.

I don't follow.  Are you saying there's value in making scp fail with
no meaningful error indication where rcp would do the same?  I don't see
it.  I think making scp successfully transfer a file even though rcp would
not would be a good thing.

>Fix your startup scripts.  

I assume the fix you're talking about is making the startup scripts detect
that the shell isn't really interactive (I'm not sure how it would) and
running the scp command as if it were a shell script instead?  Or is it
making the shell never produce any output, even when a human is there
looking?

I don't know if I made it clear, but the shell is smart enough to
perform differently in each of the three ways one might start it: 1) a
login shell -- in this case, it might issue greetings, read mail,
etc.; 2) an interactive non-login shell -- no greetings, but still
possible interactions with a human user and environment settings
relevant to an interactive session; 3) noninteractive shell -- this is
just a program interpreter, so it doesn't do anything but run the
commands you feed it.  Ssh goes out of its way to create (2), defining a
pseudo terminal so that the shell believes it is talking to a 
person.  It can't then turn around and say the shell must understand that
there's no person there.

If I'm going to make special adjustments to my system to make scp
work, it would make more sense just to run a local version of scp that
does a better job of emulating a person than to put special cases into
my interactive shell.  (And that's not a big deal for me -- I'm just
trying to save others some trouble).

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California