Re:Call for testing: OpenSSH 8.0
by jolmg on Friday March 29, 2019 @11:57AM
(#19522765)
> I think it's the time to "alias scp=sftp". If the developers officially believe that scp should be retired, let's do the switch. Both are parts of OpenSSH and the commandline argument is almost identical.
I've never used sftp before. Does it offer equivalents to:
scp server:'*.pdf' .
or
scp server:'*(oc[1])' .
for getting the last created file with zsh extended globs, or
scp server:'$(custom_remote_program)' .
where custom_remote_program is shell code that outputs a list of files using server-side state?
EDIT: Reading:
> * scp(1): Relating to the above changes to scp(1); the scp protocol relies on the remote shell for wildcard expansion, so there is no infallible way for the client's wildcard matching to perfectly reflect the server's. If there is a difference between client and server wildcard expansion, the client may refuse files from the server. For this reason, we have provided a new "-T" flag to scp that disables these client-side checks at the risk of reintroducing the attack described above.
I guess, I'll actually want:
alias scp='scp -T'
or just use `-T` on a need by basis. I admit I don't need that feature every week, but it is a relief that they didn't remove the functionality outright. I think the closest equivalent is something like:
ssh server 'tar c $(custom_remote_program)' | tar xC destination
I've never used sftp before. Does it offer equivalents to:
or for getting the last created file with zsh extended globs, or where custom_remote_program is shell code that outputs a list of files using server-side state?EDIT: Reading:
> * scp(1): Relating to the above changes to scp(1); the scp protocol relies on the remote shell for wildcard expansion, so there is no infallible way for the client's wildcard matching to perfectly reflect the server's. If there is a difference between client and server wildcard expansion, the client may refuse files from the server. For this reason, we have provided a new "-T" flag to scp that disables these client-side checks at the risk of reintroducing the attack described above.
I guess, I'll actually want:
or just use `-T` on a need by basis. I admit I don't need that feature every week, but it is a relief that they didn't remove the functionality outright. I think the closest equivalent is something like: which I'd rather not be writing.