On Sun, Jun 25, 2017 at 09:59:35PM +0200, Paul de Weerd wrote: > On Sun, Jun 25, 2017 at 06:22:05PM +0200, Job Snijders wrote: > | Dear Alexander, > | > | On Sun, Jun 25, 2017 at 06:13:40PM +0200, Alexander Hall wrote: > | > On June 25, 2017 2:06:20 PM GMT+02:00, Job Snijders <j...@instituut.net> > wrote: > | > >This patch adds a -v option to cp(1) for more verbose output. > | > > > | > > $ touch a b; mkdir c > | > > $ cp -v a b c > | > > 'a' -> 'c/a' > | > > 'b' -> 'c/b' > | > > $ cp -rv c d > | > > 'c' -> 'd/' > | > > 'c/a' -> 'd/a' > | > > 'c/b' -> 'd/b' > | > > | > Pardon my ignorance, but why? > | > | A fair question. I myself have two use cases, but others may have their > | own to add. > | > | When a glob pattern is used, it can be beneficial to immediately observe > | (during the execution of the command) which files have been copied. > | > | When copying very large trees, the -v option provides some insight as to > | what progress the cp operation has made so far. > > I like the -v option for the above reason most (and have missed it on > several occassions): copy, move or remove a whole bunch of files; it > takes a while. Is it working? Or is NFS stalling / IO to the storage > device otherwise acting up? > > Also, when using these tools in crons, it can be very useful to have > cron send out reports of the files copied/moved/deleted. Note that > directories can be altered outside of the control of said script: it > is impossible to deterministically figure out what cp/mv/rm did after > (or before, as the 'study `find *`' hint suggests) they are run. > > | Alternatively one can use rsync(1), but that is not part of the base. > > That may work for cp(1), but it's hard to replicate mv(1) behavior > with rsync (only metadata changes when on the same fs) or even > impossible to replciate rm(1) behavior.
Technically it could be possible to replicate mv with rsync --remove-source-files ... :)
