On 01.02.25 22:30, Christoph Groth wrote:> An --interactive option that behaves just like the one in cp would solve > the issue for me. I would happily alias scp to scp --interactive. Is > there any technical or other reason why scp does not have such an option > or something similar?Seeing that (the PUT command in) sftp doesn't have such an option, either, I suspect that it might indeed be a protocol issue. However, one question, in case the protocol *does* allow for such an option: What do you propose should happen when an "scp --interactive" runs into one of the cases where scp has to fall back from the SFTP protocol to ye olde scp/rcp mechanisms? Ignore the option (and silently overwrite files), bug out with a fatal "not supported by server", ... ? Kind regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4336 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20250202/4af67692/attachment.p7s>
On Sun, 2 Feb 2025, Jochen Bern wrote:> On 01.02.25 22:30, Christoph Groth wrote: > > An --interactive option that behaves just like the one in cp would solve > > the issue for me. I would happily alias scp to scp --interactive. Is > > there any technical or other reason why scp does not have such an option > > or something similar? > > Seeing that (the PUT command in) sftp doesn't have such an option, either, I > suspect that it might indeed be a protocol issue.It's not a protocol issue, someone just needs to write the code. If someone wants to try this, it's not particularly hard but it needs to be implemented for the download and upload cases separately. Once done it would be pretty easy to have it available both for interactive sftp and command-line scp (when using sftp as a transport). Also, we don't really do --long-options in OpenSSH, but both GNU and BSD cp support -i for --interactive, so that should be fine. -d