BUG: scp -r follows symlinks

[Ben Lindstrom]

On Tue, 6 Jan 2004, Edward S. Peschko wrote:

> On Tue, Jan 06, 2004 at 04:13:07PM +0100, Christian Vogel wrote:
[..delete crap..]

> ps - as for sftp, again, that's script-unfriendly. Any time you need to cat out to a
> file, or make a temporary file, or somesuch just to automate something you are causing
> one more headache for the script maintainer in the form of cleanup.
>

If you wish to make it more useful I suggest either you start coding or
explain why it is "Script-unfriendly"?  Do we not know about "sftp -b foo
user at site"?

> And you are also causing one more inconsistancy: if I create a '-r' for sftp, and
> -r handles 'symlinks the right way', then people are rightly going to wonder why
> that sftp and scp do things differently with the same flag.
>

sftp currently has no recursive concept to start with.  People are already
complaining about that.  I've seen two patches (and commented on them,
but have seen no follow up work) and I've prototyped out half of a patch
using fts().

> If you make it a different flag, and it does recursive copies, people are going to
> wonder why you made two similar flags with two separate functions.
>

Doubtful.. UNIX is full of this stuff.  People live with it.

> And finally, if you use sftp for what I suggest, you *still* won't be able to
> do statements of the form
>
> scp -r -n user at host1:/dir user at host2:/dir2
>

IFF user at host2 does not prompt for passwords or secondary auths.

sftp could support this if again.. <cough> someone who needed it were to
write the code.

Besides what people don't realize is "scp user at host1:file user at host2:file"
does not copy the file to your host then to host2.  But does
"ssh user at host1 'scp file user at host2:file'".

[..delete rest of junk I don't care about..]

- Ben