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

[Markus Friedl]

On Mon, Jan 28, 2002 at 05:33:26AM -0800, Dan Kaminsky wrote:
> > On Mon, Jan 28, 2002 at 04:46:47AM -0800, Dan Kaminsky wrote:
> > > 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?
> >
> > always.
> 
> *laughs* Me, Mr. "Encapsulate it all and let God sort it out", arguing for
> integration?  Quelle horror!

??? scp has _zero_ to do with ssh.

> Look.  bin/ssh integrates shells, commands, and TCP port forwards into a
> multiplexed cryptographically secure session.
> 
> bin/scp integrates file transfer into a multiplexed cryptographically secure
> session.

scp just happen to call 'ssh'. it can use every 8bit clean channel.

scp just does rcp over some transport protocol.

> We *could* encapsulate file transfer any number of ways -- we could TCP
> forward HTTP, we could use my various cat/tar/ls hacks, we could do any
> number of things.  Implementation-wise, we actually do encapsulate scp
> inside of ssh.
> 
> But as far as the user knows, scp is the integrated alternative to various
> other methods.  They chose the self-contained entity, distributed as part of
> SSH, that provides rcp-style semantics to access files on remote hosts.
> There are times where I want to deal with the various aspects of packaging
> one system inside of another -- but the SSH way is to integrate to a point
> and then encapsulate the rest.  We can depend on the ability to transfer
> files, much as we can depend on the ability to forward ports or access our
> remote shells with fully correct terminal support.
> 
> It's a different approach.  It's not the same as rsync, it's not the same as
> tar.  But forcing scp into the encapsulation paradigm is conceptually
> incorrect -- you're leaking implementation details into what is
> psychologically just another entity ssh supports.

but _you_ are linking scp to ssh, so you are leaking implementation details.

> Sure, a different command
> line is needed, and we need to specify files to move instead of commands to
> remotely execute -- but in the end, "ssh supports file transfer, because
> file transfer is important".
> 
> Heh.  I don't like SCP; I find it limiting.  But I see where its users are
> coming from, and really, all it costs us to support command parity is the
> non-usage of -rBSDf for file-transfer relevant options in ssh.  This is a
> small piece of latitude for what is clearly a very important knob for users
> to be able to easily tweak!
> 
> Regarding ports -- I built a patch a while back to allow this syntax.  Any
> objection to it?
> 
> ssh user at host:port
> scp user at host:port:/path .
> 
> this mirrors standard URL syntax pretty closely.

it does not support ipv6 addresses.