Can you get cp to give a progress bar like wget? | Hacker News Reader

Can you get cp to give a progress bar like wget?

chris-lamb.co.uk

148 pointsdfox33 comments

  size=`wc -c a` ; cp a b & sleep 1 ; ETA 'wc -c b' $size

Every 10 seconds it runs the given command, then gives an ETA to the number you want. It's not a progress bar, but it is a projected time of completion and can easily be extended if you want.

http://news.ycombinator.com/item?id=1149364

ETA is like pv but for those occasions when you don't have access to the data stream in a pipe. It can be used anytime you can compute a number that indicates how far along you are. Just give it the command to run for itself, or run the command and feed the values to ETA on stdin and it will give you regular estimates of when it will hit the given target.

It also lets your cp run at full speed, unlike when you copy through pv, and is more generic than just checking on the progress of specifically a copy command. It lets you predict the completion time of anything measurable.

Thanks! that looks useful... I completely missed your submission the first time you posted it

You are not alone:

http://news.ycombinator.com/item?id=1151791

Easier: install Pipe Viewer (http://www.ivarch.com/programs/pv.shtml) and, instead of

  cp a b

run

  pv < a > b

I like pv and find myself using it when bziping large files (where the blocker is bzip). It must have a negative impact on the speed of a copy.

*Hmmm, I can't back up my own predictions:

    cp huge blah           0.11s user 7.94s system 6% cpu 2:12.54 total
    pv < huge > something  0.12s user 8.10s system 7% cpu 1:54.86 total

I love pv. It's great because it's pretty much a drop-in for "cat" that gives you fancy progress bars. But for copy I tend to use "rsync -aP". It has progress but not a bar and just feels more like a replacement for cp to me.

For those of you interested in making it a permanent replacement for cp, you can use this Python script:

    #!/usr/bin/env python
    from sys import argv
    from subprocess import Popen
    copy_from = open(argv[-2],'r')
    copy_to = open(argv[-1],'w')
    Popen("pv", stdin=copy_from, stdout=copy_to)
    copy_from.close()
    copy_to.close()

Just alias cp to it in Bash.

Um... in what universe would you want an interactive terminal gadget to become the default implementation of cp? Yikes.

Still, nice pointer to the pv tool, which I hadn't heard of.

Still still, the linked awk snipped is awfully clever and more fun to read.

What? I think the override is fine in an interactive environment.

My team and I use a hack which overrides cd and as well as calling builtin cd it sources a script if it exists from cwd. This means you can get the exact enviroment you need for that working copy of a project.

Alternatively, you could just write a shell function:

   cp() { pv < $1 > $2; }

(Or name the function something else if you want regular cp still available.)

Quote the variables.

Ah, good point. I'm personally used to zsh, which doesn't have that particular misfeature.

Mac users will be happy to learn that:

  sudo port install pv

"just works" :-) (Well, assuming you use MacPorts anyway.)

This item has prompted me to investigate the strace command. It's one to put in the bag of things to try on occasion to make sure I don't forget it.

In the BUGS section of the man page you can find these items (amongst others):

  A traced process ignores SIGSTOP except on SVR4 platforms.

Hmm. That's useful to note.

  A traced process which tries to block SIGTRAP will be sent 
  a SIGSTOP in an attempt to force continuation of tracing.

I can understand that, although it could be surprising in practice for the unwary.

  A traced process runs slowly.

Understandable.

  Traced processes which are descended from command may be
  left running after an interrupt signal (CTRL-C).

That's definitely worth knowing.

  On Linux, exciting as it would be, tracing the init process
  is forbidden.

Damn.

On Linux, exciting as it would be, tracing the init process is forbidden.

But of course, nothing is stopping you from commenting this check out.

I use rsync --progress as a cp replacement when I feel like I need to know how the cp is going.

I use rsync -avzP exclusively now over cp ever since I tried copying ~7000 files from a USB drive and found cp choked less than 10% through. rsync is wonderful.

The -z flag to rsync is not always the best choice, specifically when copying within one machine.

If you feel the need to point out an alternative solution, then I think you have missed the entire point by a wide margin.

Nice hack. Hacks involving strace and awk are fun, the only thing that could have improved this is to somehow involve netcat too.

...somehow involve netcat too.

I was thinking of slowing the copy operation down a bit more by roundtripping it through Australia...

I think the people pointing out an alternative solution are just trying to join in the fun.

Or you could just do:

cp $SOURCE /dev/stdout | pv | cp /dev/stdin $DEST

Edit: "pv <a >b" is simpler, but isn't the game to fit "cp" somewhere? :)

That doesn't give you a progress bar because it doesn't know how big the data stream will be. You need to pass in some options to pv to give it that information.

And now enjoy copying files at only half the usual speed.

A watched progress bar never reaches 100%.

I have a screenshot with one that reached 139%.

Some distributions of 'cp' have it built in: https://bugs.launchpad.net/fedora/+source/coreutils/+bug/640...

On some BSDs (including Mac OS X) there is a signal, SIGINFO, to which cp will respond by printing out a status report. You can send this signal by typing ^T.

Ya. I was also thinking of just coding it and submitting a patch...

can also with

    $ rsync --progress file1 file2

I like your way best.

rsync -Pv from-file to-file

Reply on news.ycombinator.com