Soluzione 1:
rsync su ssh è probabilmente la soluzione migliore con --remove-source-files opzione
rsync -avz --remove-source-files -e ssh /this/dir [email protected]:/remote/dir
un rapido test fornisce;
[[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
Come menzionato da @SvenW, -e ssh è l'impostazione predefinita, quindi può essere omessa.
Soluzione 2:
Usa rsync invece di scp :
rsync -avz --remove-source-files /sourcedir [email protected]:/targetdir
Maggiori informazioni con man rsync .
Soluzione 3:
A questa domanda è stata data una risposta corretta e la risposta è stata accettata, ma dal momento che è apparsa in cima alla prima pagina, ho pensato di provare almeno a rispondere in modo più preciso, anche se meno elegante. Sì, puoi utilizzare il codice di ritorno da scp , e lo faccio spesso. Nel bash :
scp foo [email protected]:/destination && rm foo
Apprezzo il tuo punto di vista su più file per copiare e gestire correttamente gli errori nello stack, quindi per più file:
for file in bar*; do scp "$file" [email protected]:/destination && rm "$file" ; done
Quest'ultimo è pratico solo se stai usando ssh-agent , ma spero vivamente che tu lo sia.
Soluzione 4:
nella mia situazione, la porta ssh non è la 22, quindi
rsync -avz --remove-source-files -e "ssh -p $portNumber" [email protected]:/path/to/files/ /local/path/
funziona per me.
Soluzione 5:
se hai un server di destinazione più vecchio come me, non puoi usare
--remove-source-files
ma devi usare
--remove-sent-files --protocol=29
invece.