12 ms·
dd built-in progress introduced in coreutils 8.24
- vdfs 11y agoExample (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
- mahouse 11y agoCouldn't you just send a SIGUSR1 signal to see the progress?
- mshook 11y agoYou could but letting dd take care of it instead of doing it yourself is much better IMHO.
- zimbatm 11y agoWhat if you started dd without status=progress ?
- neikos 11y agoThen that's your own fault?
- zimbatm 11y agoBut surely if you could send a SIGUSR1 and get the progress it would be useful. I won't always have the foresight to put the progress argument. Maybe I expected the task to be quick but it's not.
- Gracana 11y agoUpdating dd to continuously dump text to the screen by default would probably break a lot of existing scripts.
- zimbatm 11y agoJust on SIGUSR1 would be good enough to get an idea where dd is at. And it would be on stderr, not stdout.
- Gracana 11y ago> 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?
- pixelbeat 11y agoThat's more awkward and outputs a separate line per interrupt. Also to do that programmatically (to provide progress to a program using dd underneath) is tricky to do robustly due to the default disposition of SIGUSR1. SIGUSR1 is really only a hack provided on systems that don't support SIGINFO (which is easier to generate and whose default disposition is easier to handle robustly)
- unluckier 11y agoIf you're on BSD, that'll kill dd.
- zimbatm 11y agodd 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 11y agoAs 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
- kazinator 11y agoFor one thing, nobody wants to type: mv opt=force old=oldname.txt new=/path/to/new.txt In dd it doesn't matter because it's used for "surgical" jobs where you have to think very carefully about several simultaneous numeric details.
- phjesusthatguy3 11y agoI've been using dcfldd for years now, just because of the progress bar.
- relaxitup 11y agoddrescue 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.
- proctor 11y agoi'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 11y agoIf 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 11y agoJust be very careful which direction you point those arrows :-) I've have similar nightmares about typoing `if` and `of` when using dd.
- agumonkey 11y agoQuite often, when I'm about to write a command involving `dd`, the first character I type is #.
- Tiksi 11y agoYou can also drop the `<` in that example, pv takes a file to read from as an argument: pv --buffer-size 1m /dev/sda > sda.file Will do the same thing, and give an accurate % complete progress bar.
- Luyt 11y agoI 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 11y agoI 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_ 11y agoThe `PRIuMAX` et al macros are specified by ISO C (starting with the 1999 standard), not (just) by POSIX.
- LukeShu 11y agoThat 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 :)
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- __david__ 11y agoYeah, it's ugly, but it's sadly the only way to correctly do cross platform prints where the type may or may not be 64 bit.
- _kst_ 11y agoThe `PRIuMAX` macro in particular is not necessary. It expands to a format usable for `uintmax_t`, but you can also use `"%ju"`. Both were introduced in ISO C99. (Unless your `printf` implementation doesn't recognize `"%ju"`, and the `PRIuMAX` macro and friends are defined in some non-standard system-specific manner.)
- brynet 11y agoOn 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 11y agoIt'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 11y agoThis example highlights a very useful alternative function of `watch`: to simply run a command on regular intervals without caring about the output.
- agnivade 11y agoYea, but its a pain to open another tab and run another command and switch back to this tab to see the progress. Why they didn't give a progress bar in the first place beats me.
- echochar 11y agoprogress(1) is a separate utility on BSD; one of my favorites. (Although it is also built in to BSD ftp.) I regularly use progress with dd, tar and other utilities. At least one BSD dd now has a "msgfmt" option that outputs parseable, printf-style format strings. Truthfully, I prefer it when these basic utilities are static except for fixing bugs. Using the new features in scripts means the scripts might lose some portability.
- crishoj 11y agoThere's also the pv(1) utility on Linux and OS X Homebrew: DESCRIPTION pv shows the progress of data through a pipeline by giving infor- mation such as time elapsed, percentage completed (with progress bar), current throughput rate, total data transferred, and ETA. To use it, insert it in a pipeline between two processes, with the appropriate options. Its standard input will be passed through to its standard output and progress will be shown on standard error. (edit: formatting)
- rjeli 11y agoSee: cat -v Considered Harmful by Rob Pike
- codemac 11y agoThis 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
- cnvogel 11y agoThis 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
- gedsic 11y agoI get "No repositories found"...
- zx2c4 11y agoThere's also this incredible tool that spies on processes to get real time progress: https://github.com/Xfennec/progress https://github.com/Xfennec/progress
- rkangel 11y agoI get "no repositories found" for that link.