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

[Dan Kaminsky]

> this is why i think -C -c -i should not be in scp.
> it's an accident to have them in scp.
> see what happened with -P/-p ? it's nightmare,
> you cannot have both rcp's and ssh's options
> in scp. and since scp is basically just rcp calling
> ssh, scp should have rcp's options plus _one_ simple
> way of passing options to ssh. so use -F and -o.
>
> you cannot have consistency between these 3 programs,
> so for consistency scp should have _no_ options from
> ssh, because if it _has_ then people want every option.

rcp's command line has long since been fixed; scp's command line is a bit in
flux, and ssh's command line is still growing.  That -p/-P is the only
serious conflict we've got going is pretty incredible, all things
considered.

I see where you're coming from.  Keeping ssh from stepping on scp's toes,
under my method, means we have to keep -r, -B, -S, -d, and -f(oops) out of
SSH's "file transfer relevant" set of options.  That's a loss to our
namespace.  It's a cost, yes, but the cause is pretty critical(transfering
files is often *more* important than getting a remote shell), and it pales
in comparison to requiring somebody to know the mental acrobatics of
translating:

ssh -1 user at host

to

scp -o Protocol=1 user at host:/foo .
or
scp -e "ssh -1" user at host:/foo .
or
scp -F some_file_with_Protocol_1 user at host:/foo .

or whatever.  These are awkward -- users and distributions moved the -1 up
to primary configuration real estate for a reason.

I guess my question to you, Markus, is this:  When is an option important
enough to add to the command line of ssh, but *not* for the exact same
reasons important enough to add to scp?

--Dan