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.
Even simpler: sudo cp image.iso /dev/sdb
The Cult of DD
61–70 of 178 posts
Re: The Cult of DD
#62One 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…
Re: The Cult of DD
#63Re: The Cult of DD
#64A counterpoint: dd survives not because it's good or makes sense, but explicitly because it doesn't. You wanna format a usb key? Google this, copy/paste these dd instructions, it works, move on with your life. You wanna format a usb key using something related to cat you once saw and didn't fully understand? Have fun. Both approaches have their weak points, but in any OS the answer to "How do I format a usb key" shou…
This probably has more truth than most unix admins would like to admin. "Why do we do it like that? I dunno, that's how I learned how, how do you do it?"
Embarrassingly, it took me a long time before I started reaching for man pages instead of Google. That has probably has had the biggest effect on tightening up my command line fu.
find is another tool that seems to get only one specific use case that ignores its rather large and useful toolset.
Re: The Cult of DD
#65Earlier quoted context omitted.
tail -c +17
This nearly tells you all you need to know. The other bit of info you'll want to note is that head -c +N produces as many bytes as you ask. So if you try to get the prefix using "head -c +N" and the suffix using "tail -c +N" then you'll have 1 byte of overlap. (dd's corresponding options do not suffer from this problem.)
Grab the first N bytes vs. grab everything starting from the Nth byte.
Re: The Cult of DD
#66Cult of pv. It looks to have more command-line complexity than dd. https://linux.die.net/man/1/pv
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.
$ 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
22+0 records in
22+0 records out
22000000 bytes transferred in 1.746013 secs (12600134 bytes/sec)
load: 1.76 cmd: dd 80097 running 0.00u 2.28s
31+0 records in
31+0 records out
31000000 bytes transferred in 2.392392 secs (12957742 bytes/sec)
load: 1.76 cmd: dd 80097 running 0.00u 2.83s
38+0 records in
38+0 records out
....Re: The Cult of DD
#67Earlier quoted context omitted.
Even simpler: sudo cp image.iso /dev/sdb
Would that seriously work?
Basically, you can use cp wherever you use dd, as long as you're not changing any low-level parameters (e.g. starting 500 bytes into the file or something).
Re: The Cult of DD
#68Re: The Cult of DD
#69An 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.
I'm a Linux sysadmin/developer and I've literally never used a Linux GUI.