Hacker News new | past | comments | ask | show | jobs | submit login

While I think the popularity of it in such contexts came about after this page was published, I'd also add "Useless use of dd": the application of dd to do a non-transformative copy to or from device files.

In Unix, "everything is a file" means that even hardware devices are accessible using standard file APIs, and as such, doing procedures like "cp debian.iso /dev/sdg" to write out a USB device with a bootable ISO image is perfectly valid. One could even use "cat debian.iso > /dev/sdg" if desired, though the command doesn't quite convey the same meaning as cp, nor is it a concatenate operation.

In the 21st century however, it has become popular to use "dd if=debian.iso of=/dev/sdg" instead, and for the best I can tell, I think it stems from former DOS and Windows users, that make the assumption that hardware devices are special and require special programs to access, and somehow landed on dd being the special tool. Even though dd is really meant for transformative copies -- the program was originally written to convert documents between ASCII and EBCDIC! Worse than that, too, is that dd's mechanism of reading in and writing out in fixed-size blocks means that it's often much slower than just using cp.




Pretty sure older Unixes wouldn't do "cat debian.iso > /dev/sdg" correctly, though not sure. If nothing else, 'dd' will pad out the final block, which can be handy.

Also, if you have lots of RAM and the file isn't too big, 'dd' can pull the whole thing into RAM before the first byte is written, which could be handy if you have a read I/O error.


With dd you can specify the block size with bs=1M or so. Sometimes you do need this capacity for performance reasons.


Might it also be the destructive nature of writing directly to a device might warrant a more explicit syntax, as-to avoid potential errors? There's no confirmation about copying a iso to a device directly or anything.


Contrary to cp, dd can report progress (status=progress switch)


You could use pv, which I think gives a much better progress bar.


Or the excellent progress¹ which can show progress state for already running commands, great for when a process has been running for longer than you expected. Comes with a bunch of filtering options, and can be applied to all sorts of commands as it just digs about in the file handles.

1. https://github.com/Xfennec/progress


    cat debian.iso > /dev/sdg
Does this win the award?

    < debian.iso > /dev/sdg


While cat could be argued to be overkill (... but not by me...), that's not a useless use of cat because if you pull it out (as you've done) there's nothing to actually read the bytes from stdin and write them to stdout. All you've done is opened two files and closed them again.

(Edited to add: unless you're using zsh, apparently)


Ah interesting! I do use zsh and didn't know this didn't exist in bash.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: