Solution 1 :
rsync sur ssh est probablement votre meilleur pari avec le --remove-source-files possibilité
rsync -avz --remove-source-files -e ssh /this/dir [email protected]:/remote/dir
un test rapide donne ;
[[email protected] ~]$ mkdir test1
[[email protected] ~]$ mkdir test2
[[email protected] ~]$ touch test1/testfile.1
[[email protected] ~]$ ls test1/
testfile.1
[[email protected] ~]$ rsync --remove-source-files -av -e ssh test1/testfile.1 [email protected]:/home/tomh/test2/
sending incremental file list
sent 58 bytes received 12 bytes 10.77 bytes/sec
total size is 0 speedup is 0.00
[[email protected] ~]$ ls test1/
[[email protected] ~]$
[[email protected] ~]$ ls test2/
testfile.1
Comme @SvenW l'a mentionné, -e ssh est la valeur par défaut et peut donc être omise.
Solution 2 :
Utilisez rsync au lieu de scp :
rsync -avz --remove-source-files /sourcedir [email protected]:/targetdir
Plus d'infos avec man rsync .
Solution 3 :
On a répondu très bien à cette question, et la réponse a été acceptée, mais comme elle flotte en haut de la première page, j'ai pensé que j'essaierais au moins d'y répondre plus précisément, quoique moins élégamment. Oui, vous pouvez utiliser le code de retour de scp , et je le fais souvent. En bash :
scp foo [email protected]:/destination && rm foo
Je prends note de votre point de vue sur plusieurs fichiers à copier et à gérer correctement les échecs dans la pile, donc pour plusieurs fichiers :
for file in bar*; do scp "$file" [email protected]:/destination && rm "$file" ; done
Ce dernier n'est pratique que si vous utilisez ssh-agent , mais j'espère vraiment que vous l'êtes.
Solution 4 :
dans ma situation, le port ssh n'est pas 22, donc
rsync -avz --remove-source-files -e "ssh -p $portNumber" [email protected]:/path/to/files/ /local/path/
fonctionne pour moi.
Solution 5 :
si vous avez un ancien serveur cible comme moi, vous ne pouvez pas utiliser
--remove-source-files
mais vous devez utiliser
--remove-sent-files --protocol=29
à la place.