5 ms·

strace is definitely a fun toy. Here's my favourite hack: https://chris-lamb.co.uk/posts/can-you-get-cp-to-give-a-progress-bar-like-wget https://chris-lamb.co.

• fit2rule 11y ago
  Definitely a cute hack if you don't have the pv tool around, but if you do: better to use pv than have an strace hackery dependency, imho. Still, a very good way to get started with understanding what strace is doing ..
• david-given 11y ago
  That's one of the most evil things I've seen for a long time (and I have done many evil things).
• nikanj 11y ago
  Most versions of cp also respond to ctrl-t by printing current statistics
  • raimue 11y ago
    On *BSD and OS X the keyboard command Ctrl-T sends a SIGINFO to all processes connected to the tty. Many tools such as cp, mv and even dd display their progress when they receive a SIGINFO. This signal does not exist on Linux.
• dspillett 11y ago
  Or you could replace "cp" with "rsync --progess" for everything. rsync has become a habit for me and I only use cp these days when that isn't available (or in scripts that might one day run where rsync isn't installed) or for "cp -al" (which I could possibly do with rsync too). But the strace-cp-progress hack is an interesting snippet for understanding some of the things you can do with strace.
  • vincentkriek 11y ago
    Only when doing one file. Rsync will give you the progress for the file it's working on, not the overall progress over the copy job.
    • dspillett 11y ago
      Good point, this makes a big difference when copying files of different sizes (though if copying large files of roughly the same size it is still a useful indicator).
    • alphapapa 11y ago
      You can now do: rsync --info=progress2 --no-inc-recursive ...and see total transfer progress. This requires rsync to do a full recursive scan before beginning the transfer, but sometimes it's worth it.
  • jamiesonbecker 11y ago
    Agreed! but rsync isn't nearly as fast over the network as something like this. rsync has to track tons of metadata (and the bigger the tree, the bigger the slowdown). Tar just screams (try it and compare): tar -zc /somedir/ | ssh remotebox tar -xzC /somedir/ (you can play with -z vs ssh -C, but my experience is that -z is faster because it compresses before passing across the wire; don't do both, though..) I've also had really great luck doing this on a single filesystem (tar into tar), since it does a better job with things like /dev compared to cp. rsync has a lot of other awesomeness, though, especially with its hard-link capabilities. That can save a huge amount of space on remote backups over multiple days. (We use glacier for backups at Userify (ssh key management), but we also use this trick for remote pull backup to the backups without server access.)
    • dspillett 11y ago
      The original posts were about progress indication on the file transfers, so I would add an invocation of pv in your example: tar -zc /somedir/ | pv | ssh remotebox tar -xzC /somedir/ That won't give a % done as it won't know the total size, but if you scan the source first and split out the tar and compress stages you can achieve that though it'll be a little less efficient: tar -c somedir | pv --size `du somedir -bs | cut -f1` | ssh -C remotebox tar -xC /tmp/ and if you want to keep the compression via gzip instead of ssh (I'm not sure that'll make any difference myself as ssh IIRC uses the same algorithm, though I've not benchmarked it at all): tar -c somedir | pv --size `du somedir -bs | cut -f1` | gzip | ssh remotebox tar -xzC /somedir/