Solución 1:
rsync sobre ssh es probablemente su mejor apuesta con el --remove-source-files opción
rsync -avz --remove-source-files -e ssh /this/dir [email protected]:/remote/dir
una prueba rápida da;
[[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
Como mencionó @SvenW, -e ssh es el valor predeterminado, por lo que se puede omitir.
Solución 2:
Usa rsync en lugar de scp :
rsync -avz --remove-source-files /sourcedir [email protected]:/targetdir
Más información con man rsync .
Solución 3:
Esta pregunta ha sido respondida muy bien, y la respuesta fue aceptada, pero dado que flota en la parte superior de la página principal, pensé que al menos intentaría responderla con mayor precisión, aunque con menos elegancia. Sí, puede usar el código de retorno de scp , y lo hago a menudo. En bash :
scp foo [email protected]:/destination && rm foo
Tomo su punto sobre múltiples archivos para copiar y manejar fallas en la pila correctamente, por lo que para múltiples archivos:
for file in bar*; do scp "$file" [email protected]:/destination && rm "$file" ; done
Esto último solo es práctico si estás usando ssh-agent , pero espero que lo seas.
Solución 4:
en mi situación, el puerto ssh no es 22, entonces
rsync -avz --remove-source-files -e "ssh -p $portNumber" [email protected]:/path/to/files/ /local/path/
funciona para mí.
Solución 5:
si tiene un servidor de destino más antiguo que yo, no puede usar
--remove-source-files
pero tienes que usar
--remove-sent-files --protocol=29
en su lugar.