What's this?

commandlinefu.com is the place to record those command-line gems that you return to again and again.

Delete that bloated snippets file you've been using and share your personal repository with the world.
That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and
voted up or down.

Stay in the loop…

Follow the Tweets.

Every new command is wrapped in a tweet and posted
to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning,
there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.

pv allows a user to see the progress of data through a pipeline, by giving information such as time elapsed, percentage completed (with progress bar), current throughput rate, total data transferred, and ETA. (man pv)

This is a more accurate way to watch the progress of a dd process. The $DDPID=$! is needed so that you don't get the PID of the sleep. The sleep 1 is needed because in my testing at least, if you run kill -USR1 against dd too quickly, it will kill it off instead of display the status. So you need to wait a second, probably so that it can configure itself to trap the USR1 signal.

Know a better way?

What others think

I think you meant to use just one & in the above command. Otherwise it won't run the while killall until the dd is done.

The problem with doing this is that if you do this as root or something on a multiuser system, you are going to end up sending the USR1 signal to any dd that is running. So you can imagine if another user was running dd and suddenly they say the status output from it, they might wonder what the hell is going on. You could use $! to get the PID of the last process you ran.

However, in the interest of improving upon your idea, I found out something interesting about the dd command. Apparently, if you pass the USR1 signal to it too quickly, it just dies.

At least on my system, the dd dies immediately, I guess because it received the USR1 signal before it could set it self up to trap it. So you have to do this in order to delay it enough so that you don't kill the dd:

On OSX (Mountain Lion) dd wants `-SIGINFO`, not `-USR1` and also for some reason DDPID was being assigned the process *before* the current one so I had to run the signal loop in a separate terminal window after `ps aux | grep dd`-ing to get the process number. Thx though. I've learned a lot just now!