[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