121–130 of 178 posts
Earlier quoted context omitted.
There is a trivial alternative. Just use a subshell. sudo (cat ... > target)
I don't know if this works but I believe it doesn't.
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…
Author is wrong bs IS useful, try to dd one hard drive to another without reasonable bs (1-8M) with and without and you will see a difference.
It also doesn't care about file type. If you want to copy a malformed file dd will do it - cat won't.
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.
This is a great example of why downvoting submissions should be a thing. Or at least showing the up/down tuple. I would say every upvote represents someone misled and likely to further propagate this nonsense.
You can flag submissions.
"This is a strange program of obscure provenance that somehow, still manages to survive in the 21st century." -> links to wikipedia page with direct discription of lineage back to 5th ed research unix "That weird bs=4M argument in the dd version isn’t actually doing anything special—all it’s doing is instructing the dd command to use a 4 MB buffer size while copying. But who cares? Why not just let the command figure…
The other reason for dd existence is that back in the day if you wrote to a block device with a write(2) size of anything other than a multiple of the devices actual block size you'd get a EIO or a EINVAL. So the program you used to make sure the write(2) size was always correct was dd. In the old days some truly weird block devices would accept a write(2) that used only the exact block size, i.e. you could only read…
It's not back in the day, it's still true. In Linux, block devices are kernel-cached by default, unless opened with O_DIRECT flag.
In general UNIX case (for example, FreeBSD), they aren't: https://www.freebsd.org/doc/en/books/arch-handbook/driverbas...
So, in FreeBSD "dd bs=1" will fail if it involves any disk device: disk driver will return EINVAL from read(2) or write(2) because I/O size is not divisible by physical sector size. "cat" with buffer size X (which depends on implementation) will work or not depending on divisibility of X by physical sector size, and other random factors, like short file I/O caused by delivery of the signals.
Summary: dd(1) still has its place and author of original article is getting it wrong.
Earlier quoted context omitted.
>> if you want progress information with cat you can combine it with the pv command Since coreutils-8.24[1], dd "accepts a new status=progress level to print data transfer statistics on stderr approximately every second." > Because the command probably doesn't figure out the right size automatically . . . this can mean massive performance differences between invocations For anyone who's wondering, here are two good t…
Or, before that, just send the dd process SIGINFO to get the same output printed once. `while :; do kill -INFO %1; sleep 1; done` if you want a "progress bar" of sorts. As an aside: On BSDs (incl. macOS), SIGINFO is also able to be sent interactively by the line driver when you type ^T (like ^C sends SIGINT.) Kind of lame that Linux doesn't follow suit [or even have SIGINFO], or we'd see a lot more programs that buil…
Earlier quoted context omitted.
>> if you want progress information with cat you can combine it with the pv command Since coreutils-8.24[1], dd "accepts a new status=progress level to print data transfer statistics on stderr approximately every second." > Because the command probably doesn't figure out the right size automatically . . . this can mean massive performance differences between invocations For anyone who's wondering, here are two good t…
Or, before that, just send the dd process SIGINFO to get the same output printed once. `while :; do kill -INFO %1; sleep 1; done` if you want a "progress bar" of sorts. As an aside: On BSDs (incl. macOS), SIGINFO is also able to be sent interactively by the line driver when you type ^T (like ^C sends SIGINT.) Kind of lame that Linux doesn't follow suit [or even have SIGINFO], or we'd see a lot more programs that buil…
cat image.iso | pv >/dev/sdb
pv /dev/sdb
echo "foo" | bar
bar bar