Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Cult of DD

eklitzke.org

Post reply on HN
Print view View original

51–60 of 178 posts

Re: The Cult of DD

#51

Post by schoen »

tambourine_man wrote: post #41

But who cares? Why not just let the command figure out the right buffer size automatically? Because it can be a lot slower. dd is low level, hence powerful and dangerous. And, if we are going down that rabbit hole, you don't need cat[1] “The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process.” [1] http://porkm…

But if you don't use any process, what process is doing the reading?

(This sounds like a zen koan somehow.)

Re: The Cult of DD

#52

Post by 2bitencryption »

gravypod wrote: post #21

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.

"a paintbrush should be reserved for times when you need fine grain control to paint your bedroom. A hired painter could do it all reliably in a way that doesn't risk you painting over the crown moulding or falling off a ladder."

Re: The Cult of DD

#53

Post by schoen »

ocschwar wrote: post #48

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.

The biggest counterexample to this that some people have experienced is accidentally swapping if= and of=, thus backing up their target onto their source rather than vice versa.

Re: The Cult of DD

#54

Post by schoen »

emmelaich wrote: post #33
merlincorey wrote: post #30

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.

Nice! MacOS has it too (unsurprisingly) Linux, not. I wonder why.

Huh, I never knew about this. It looks like Linux doesn't define SIGINFO, which is what the terminal driver would generate in response to the ^T.

Re: The Cult of DD

#55

Post by GalacticDomin8r »

merlincorey wrote: post #30
donaldihunter wrote: post #22

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 available on at least FreeBSD as a package like it is in Linux. I'd be quite shocked if the other BSD's didn't have a port of it as well. There is also mbuffer.

SIGINFO works on gnu dd last I tried it.

Re: The Cult of DD

#56

Post by dredmorbius »

schoen wrote: post #51
tambourine_man wrote: post #41

But who cares? Why not just let the command figure out the right buffer size automatically? Because it can be a lot slower. dd is low level, hence powerful and dangerous. And, if we are going down that rabbit hole, you don't need cat[1] “The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process.” [1] http://porkm…

But if you don't use any process, what process is doing the reading? (This sounds like a zen koan somehow.)

I like the koan. But the point should be an additional process.

In a UUOC avoidance case, it's the current process which reads, generally via stdin. Say, the shell, or dd itself with an 'if=' parameter.

Which I strongly suspect you know.

Re: The Cult of DD

#58

Post by tracker1 »

gravypod wrote: post #21

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've setup/configured bind a few times, and every time I wish there was a nice gui for it.. even thinking to myself I should make one.. but shortly after I've refreshed my memory of how to do something, and by then, I'm done and leave it alone for some while.

Re: The Cult of DD

#59

Post by electrum »

Don't cat a file and pipe it into pv. Use "pv file" as a replacement for "cat file" and it will show you the progress as a percentage. When it's in the middle of a pipeline, it doesn't know the total size (unless you tell it with -s), so it can only show the throughput.

Re: The Cult of DD

#60

Post by smacktoward »

schoen wrote: post #51
tambourine_man wrote: post #41

But who cares? Why not just let the command figure out the right buffer size automatically? Because it can be a lot slower. dd is low level, hence powerful and dangerous. And, if we are going down that rabbit hole, you don't need cat[1] “The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process.” [1] http://porkm…

But if you don't use any process, what process is doing the reading? (This sounds like a zen koan somehow.)

When the file is ready, the process appears?

:-D

Post reply on HN