On Jan 24 03:47, Malcolm wrote: > Quoting Chris High <highc@xxxxxxxxxx>: > > > caught my eye. Do you see any 'advantage' to using sftp with an untrusted > > server? If so, any thoughts about making an easy way to disable scp both > > client and server side when doing an installation? > > SFTP allows file resume, while scp does not. If this isn't the case, I'm > welcome to be corrected. > > scp's command line interface is intuitive and reasonably sensible, especially > as a follow-on to ncftp/friends like interfaces, a la local->remote/remote-local. > > Problem is, scp doesn't let you resume interrupting up/downloads. So we have > to use the nasty/non-CLI-friendly sftp thing, which doesn't (seem) to support > fairly straightforward mechanisms (user@hostname:/file/pathname/object <-> > local object sort of stuff. > > There are too many arbitrary "issues" between the sftp/scp/ftps > implementations to sort for end-users for them to pick outside of which one > "gets the job done". > > I wish there was a way for either sftp to get scp-like interfaces, or scp to > get all of the functionality of sftp, so the 'other' can die the ignominious > death it deserves. What's missing in sftp is a drop in replacement mode for copying to the remote server, i.e. this should work out of the box: $ sftp -rp local_dir server:path But, alas: ssh: Could not resolve hostname local_dir: Name or service not known If sftp had this mode, I would alias scp=sftp and be done with it. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
