Show HN: Linux tool to show progress for cp, rm, dd, etc.
github.com
github.com
If cp receives a SIGINFO (see the status argument for stty(1)) signal,
the current input and output file and the percentage complete will be
written to the standard output. kill -s <Signal> <Process ID> pkill -USR1 dd
You'll need to use ps to get the pid if you've got multiple dd instances running, and you'll of course need to run that as root if your dd instance is running as root.You can check dd progress by sending USR1, for example.
> rsync --progress <source> <destination>
> rsync --progress /home/me/music/*.mp3 /mnt/shared/music
(It doesn't do all the rsync fanciness, but if you don't need that and/or you've got some unwieldy subset of files to transfer - a situation the GUI-style approach makes light work of - then it comes in handy.)
It would be nice for cp and mv to just have built-in progress bars (only active in interactive mode, etc).
Here's the POC if anyone would like to take it further: http://anthias.sourceforge.net/
tar c -C /tmp/source . | pv | tar x -C /tmp/dest
you can also pass an approximated size of your source to pv, however the tar output will be slightly bigger.
A bit clumsy, but it shouldn't be hard to write a little script to do it.
Anyway, if cp -R had a progress bar it would behave the same way, i.e. it would have first to recursively stat the source the same way as du does, and only then it could start reporting a completion percentage.
ps -A | grep -P 'cp|dd' | sed -r 's/^\s*([0-9]+).+$/\1/' | xargs kill -s SIGINFOAnd did you really just reinvent pkill?
I had a 2TB drive turn up five figure error rates (Raw Read Error rate ended up at 90k - when I started, it was already no longer possible to mount it, but it did show up in /dev) and thought I had lost an entire year of family pictures (mea culpa on not having a backup, of course). It took four months, 24/7 of meticulous work, but it ended up giving me a near perfect copy to an identical drive (save for ~20kb of truly dead sectors).
Amongst many other features, it has a logfile where it keeps track of the overall process - so that it can be killed or paused and restarted later.
I'm not too familiar with what file libs or utils can be used to handle this as the author says this relies on a linux specific header file and tool.
aeg@bigwibble ~/ % cp bigfile /Volumes/data_sd1
load: 1.60 cmd: cp 17686 uninterruptible 0.00u 0.09s
bigfile -> /Volumes/data_sd1/bigfile 1% [/tmp]$ cp bigfile bigfile2
load: 1.78 cmd: gcp 93420 running 0.00u 0.04s
load: 1.78 cmd: gcp 93420 running 0.00u 0.10s
load: 1.80 cmd: gcp 93420 uninterruptible 0.00u 0.16s
load: 1.80 cmd: gcp 93420 uninterruptible 0.00u 0.26s
[/tmp]$Try: /bin/cp bigfile bigfile2
I've been using patched copies of coreutils to do the same thing, this is much better.
By the way, if you ever need to quickly spy on rsync you can try this:
watch lsof -ad3-999 -c rsync
but there is a chance cv will work with rsync too and be more helpfulhttps://chris-lamb.co.uk/posts/can-you-get-cp-to-give-a-prog...
(Sorry, really bad joke...)