[PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1

Dan Kaminsky dan at doxpara.com
Tue Jan 29 08:06:13 EST 2002


> they are "implemented" with -o.

First of all, -o presumes an SSH backend.  Markus's argument that SCP has
nothing to do with SSH thus doesn't work, the _S_ stands as much for SSH's
as it does Secure.  It ships with it, it uses it by default, it
authenticates using the same means normally.

Second of all, you *hide* unimportant or rarely needed things with -o.
There's, what, fifty four options supported in readconf.c?  We don't need to
support all of 'em, but those that have critical impacts certainly have
priority.

===

Ben, the first patch I ever wrote for OpenSSH added -1/-2.  It was trivial
enough that I just did it myself, and this was before I even understood the
codebase.

===

Markus:

>> SCP is *the* standard method of transfering files over SSH.
>
>it there _was_ a standard method, just look at the
>scp1/scp2/sftp mess

I didn't say it was a good standard.  Remember, _I_ hate SCP, and don't
think SFTP is even close to mature yet.  (Mindterm's SFTP bridge,
incidentally, is so breathtakingly elegant that it's challenging my SOCKS
solution.)

> -c, -C, -i got added, while -p could not, -f could not, -t could not,
> -P could not, so there is already a _big_ difference, and now with this
> inconsistency people started expecting that scp accepts all options
> from ssh. but that's not possible. adding more options to scp will make
> even more people expect that scp and ssh behave the same. but they
> cannot behave the same, it's too late.

Oh, fooey.  You're making way too big a deal of this than it is.  Go *look*
at the command line options we support in bin/ssh and don't in bin/scp.
Yeah, we conflict on ports, and that sucks, but we need a better port syntax
anyway.  -t doesn't mean anything, there's no tty involved.  -f is a toy
that's matched simply by typing

scp -q user at host:/file . &

So we're left with being unable to use -r, -B, -S, and -d in ssh for any
option that scp might possibly want to use.  BFD.

You want consistent -o availability throughout all s* client apps.  I say,
heh, great idea.  But whenever we go ahead and say, look, something is so
important that we're going to add it to the command line of ssh, I say that
change should propagate through the rest of the s* apps.  If nothing else,
it'll prevent the quick command line namespace from getting too crowded.

We BOTH want consistency, Markus.  If it was important enough to add to
ssh -- and for 1/2, oh yes it was -- it's important enough for the rest of
the s* clients.

Anyway, I'm done with this thread.  I've said what I needed to say, and to
be blunt, I've been enough of a gasbag :-)  No more from Dan until patches
are submitted.  That's a promise.

--Dan





More information about the openssh-unix-dev mailing list