
dd built-in progress introduced in coreutils 8.24 - vdfs
http://git.savannah.gnu.org/cgit/coreutils.git/commit/src/dd.c?id=af2a4ed22594badd2719c0123441d69b17bd8328
======
brynet
On BSD, unlike Linux, many utilities including dd(1) will dump a progress
report when receiving SIGINFO. This was traditionally bound to ^T in shells,
either by default or using stty(1).

~~~
justin_vanw
It's SIGUSR1 on Linux, however there is no signal bound to ^T in Linux, nor is
it apparently possible to bind new ones.

`killall -USR1 dd` works like a charm, or for the impatient: watch killall
-USR1 dd

~~~
oxplot
This example highlights a very useful alternative function of `watch`: to
simply run a command on regular intervals without caring about the output.

------
cnvogel
This is how it looks...

    
    
        [sc-lx-phys-05 /home/cvogel]
        $ dd if=/dev/zero of=/dev/null status=progress
        11086075904 bytes (11 GB) copied, 7.000001 s, 1.6 GB/s

------
Luyt
I find this style of formatting specifiers an eyesore:

    
    
        fprintf (stderr,
                _("%"PRIuMAX"+%"PRIuMAX" records in\n"
                  "%"PRIuMAX"+%"PRIuMAX" records out\n"),
                r_full, r_partial, w_full, w_partial);

~~~
LukeShu
I assume you mean the `%"PRIuMAX"` bits. It is an eyesore, but it is how to
portably write the specifiers for types whose size my vary across
architectures. That is, blame POSIX, not GNU coding style.

~~~
_kst_
The `PRIuMAX` et al macros are specified by ISO C (starting with the 1999
standard), not (just) by POSIX.

~~~
LukeShu
That makes sense; the most recent editions of POSIX "import" ISO C '99\. I had
a copy of POSIX handy to check it, but not ISO C :)

------
proctor
i've found that pv is useful for this purpose. however i've never been quite
clear on what the best way to use bs with pv is. is it

    
    
      dd if=/dev/sda bs=1M | pv > sda.file
    

or is this better

    
    
      dd if=/dev/sda bs=1M | pv | dd of=sda.file bs=1M

~~~
rogerbinns
If all you are doing is the above, then you don't need dd at all. pv will act
like dd (but with stdin/out) and uses a sensible buffer size you can override.
Your first example becomes:

    
    
      pv --buffer-size 1m < /dev/sda > sda.file
    

[http://www.ivarch.com/programs/quickref/pv.shtml](http://www.ivarch.com/programs/quickref/pv.shtml)

    
    
      -B BYTES, --buffer-size BYTES
        Use a transfer buffer size of BYTES bytes. A suffix of "k", "m", "g", or
        "t" can be added to denote kilobytes (*1024), megabytes, and so on. The 
        default buffer size is the block size of the input file's filesystem 
        multiplied by 32 (512kb max), or 400kb if the block size cannot be 
        determined.
    

pv is great tool and works really well. On Linux you can even point it at
other process ids, and it will automatically scan their open file descriptors
and show progress of relevant ones.

~~~
ckuehl
Just be very careful which direction you point those arrows :-)

I've have similar nightmares about typoing `if` and `of` when using dd.

~~~
agumonkey
Quite often, when I'm about to write a command involving `dd`, the first
character I type is #.

------
zx2c4
There's also this incredible tool that spies on processes to get real time
progress:

[https://github.com/Xfennec/progress](https://github.com/Xfennec/progress)

------
zimbatm
dd was always a big special to me. It's the only command-line utility that I
know that takes the simple approach to argument parsing. I don't know why
everyone wants to prefix their arguments with --

~~~
pixelbeat
As mentioned in the online manual at
[http://gnu.org/software/coreutils/dd](http://gnu.org/software/coreutils/dd)
that command line syntax is inspired by the DD (data definition) statement of
OS/360 JCL

------
phjesusthatguy3
I've been using dcfldd for years now, just because of the progress bar.

~~~
relaxitup
ddrescue also shows progress by default. Not sure if it has a comparable
feature-set as dcfldd, but for data rescue/forensics, it definitely does the
trick, and seems to be much more actively maintained.

------
vdfs
Example (from Reddit post): # dd if=arch.iso of=/dev/sdb bs=4M status=progress
61432564 bytes (61 MB) copied, 3.024017 s, 20.3 MB/s

~~~
iofj
Is a progress bar or percentage really that much to ask ?

~~~
amalcon
You don't always know how many bytes remain to be copied, e.g. in the case of
a FIFO. It could theoretically do things differently in the cases where you do
know, however.

------
gedsic
I get "No repositories found"...

------
rkangel
I get "no repositories found" for that link.

------
rjeli
See: cat -v Considered Harmful by Rob Pike

~~~
codemac
This is a pretty useful feature for something that regularly copies large
files/disks you'd want to see the progress of, in fact I'd say it should have
been default behavior for years.

I'd make some crude comment about cargo culting, but do you have an explicit
complaint? dd itself is derided by the plan9 crew for many more reasons than a
progress bar, and the cli arguments are obtuse because they're a joke.

[0]:
[http://www.catb.org/jargon/html/D/dd.html](http://www.catb.org/jargon/html/D/dd.html)

------
mahouse
Couldn't you just send a SIGUSR1 signal to see the progress?

~~~
mshook
You could but letting dd take care of it instead of doing it yourself is much
better IMHO.

~~~
zimbatm
What if you started dd without status=progress ?

~~~
Gracana
Updating dd to continuously dump text to the screen by default would probably
break a lot of existing scripts.

~~~
zimbatm
Just on SIGUSR1 would be good enough to get an idea where dd is at. And it
would be on stderr, not stdout.

~~~
Gracana
> it would be on stderr, not stdout

Oh, that's true.

Anyway, what behavior do you want to see exactly? You can still send the USR1
signal and get the update behavior just like before. Were you just pointing
out that there are cases where you still need to use that feature, or
something else?

