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.
Cheers,
Paul 'WEiRD' de Weerd
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
