Live data from Hacker News

The Cult of DD

eklitzke.org

61–70 of 178 posts

Re: The Cult of DD

#61
post #49

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

Would that seriously work?

Re: The Cult of DD

#62
post #38

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.

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…

ddrescue is excellent.

Re: The Cult of DD

#64
post #34

A 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?"

Definitely this. I have found many times that I'm an offender of these "bad practices", and usually that's because a certain pattern I learned way back in the beginnings of my Linux days still hangs around.

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

#65
post #28

Earlier 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.)

That seems pretty intuitive to me:

Grab the first N bytes vs. grab everything starting from the Nth byte.

Re: The Cult of DD

#66

Cult 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.

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
  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

#67
post #61
post #49

Earlier quoted context omitted.

Even simpler: sudo cp image.iso /dev/sdb

Would that seriously work?

Yep! See this: http://askubuntu.com/questions/751193/what-is-the-difference...

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

#68
One of the charms of dd is its hilarious syntax. And, used properly, it's a bit of a swiss army knife for a few different disk operations.

Re: The Cult of DD

#69

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.

I'm a Linux sysadmin/developer and I've literally never used a Linux GUI.

I want to do this so bad, but the two things that keep me running X are my browser and mpv. Oh, and viewing PDFs.

Re: The Cult of DD

#70
One of the charms of dd is its hilarious syntax. And, used properly, it's a bit of a swiss army knife for a few different disk operations.
Post reply on HN