171–178 of 178 posts
OP, your alternatives to DD are more complicated, not less complicated. I shouldn't need to pipeline two commands together just to cut off the first 100MB of a file.
* Using "cat source > target" instead of "cp source target"
* Using "cat source | pv > target" instead of "pv source > target"
* Using "head -c 100MB /dev/zero > target" instead of "truncate -s 100MB target"
There's one good (?) reason to use dd with devices: it specifies target in the same command. For devices, writing to them usually requires root privileges, so it's easy to: sudo dd .... of=/dev/... But there's no trivial cat equivalent: sudo cat ... > target Will open target as your current user anyway. You can play around with tee and redirection of course. But that's getting more complicated than the original.
sudo bashOne thing I'll often use dd for is recovering data from a failing drive. Can head ignore read errors? dd can. As far as I'm concerned, dd is lower-level than most of the other utilities and provides more control over what's happening. The author does have a point that the syntax is strange though.
dd is awful and error-prone for this sort of use. Use noerror, but forget sync? Corrupt output file if there is an error. Use a bigger bs so it's not slow as treacle? A single faulty sector blows away a whole bs of data, and your output image may get unwanted padding appended to the end. Recoverable error? dd's not going to retry. Use ddrescue or FreeBSD's recoverdisk(1). They're faster, they're safer, they're more e…
[1]: http://www.gnu.org/software/ddrescue/ddrescue.html [2]: http://www.garloff.de/kurt/linux/ddrescue/
One thing I'll often use dd for is recovering data from a failing drive. Can head ignore read errors? dd can. As far as I'm concerned, dd is lower-level than most of the other utilities and provides more control over what's happening. The author does have a point that the syntax is strange though.
Earlier quoted context omitted.
This is a good point as well. On BSD, we don't have `pv`, but we do have ^T. This will print some sort of status for just about any long running process. It prints very specialized status for certain programs aware of it.
pv is probably more useful: $ dd if=/dev/urandom count=1000 bs=1000000 | pv -s 1000000000 > foo 214MiB 0:00:16 [13.1MiB/s] [========================> ] 22% ETA 0:00:55 Compare to ^T: $ dd if=/dev/urandom of=foo count=1000 bs=1000000 load: 1.76 cmd: dd 80097 running 0.00u 0.89s 11+0 records in 11+0 records out 11000000 bytes transferred in 0.947316 secs (11611752 bytes/sec) load: 1.76 cmd: dd 80097 running 0.00u 1.68s…
Dude's missing an important point: If you mess up the syntax on a dd invocation, a nice thing happens: nothing. Use a shell command and pipes, and your command better be perfect before you hit return.
though I'm not a fan of this article by any means, I've definately dd'ed the wrong disk before and slapped myself for doing so.. Usually it's not past the easily-reproducable system partition yet or on a data disk that is backed up regularly so I can recover in an hour or so..
An even easier solution: don't make people fall into the command line to format a USB reliably. The command line should be reserved for times where you need the fine grain control to do something that DD is meant to do. A GUI should implement everything else in a reliable way that doesn't break half the time or crash on unexprected input.
The better half of my computer use happens in the command line interface, way more efficient use of my time.