For most linux users, “dd” is mostly used when dealing with disk issues, such as copying one disk to another (byte for byte) creating an ISO from a CD/DVD, and so on. I personally didnt know what else I would use dd for until I ran across a particular need….
I needed my linux script to read data from a bluetooth sensor (this of course applies to other I/O devices like USB, etc). Normally, using the /dev filesystem it’s quite easy to read and write to devices. However, this is true only when the data being read from the sensor has a defined start and end. For example, in my case, normally reading from a bluetooth sensor would involve a simple command like “cat /dev/rfcomm0“. The bluetooth sensor connects, sends data, and disconnects. The disconnect is a measurable “end” to the data… most of the time the disconnect action deletes the /dev/rfcomm0 device and so the “cat” command exits and the script can continue processing.
But what happens if the data sensor sends a continuous data stream? In this case there is no “end” event, and the cat command would continuing on spewing output, but would never stop and pass control over to the next command in the script. This creates a problem to the script author… how to read a discrete set of data from the sensor, then pass on to the next command?
That’s where DD came into the picture. Rather than using “cat /dev/rfcomm0” we could use something similar to “dd if=/dev/rfcomm0 bs=8 count=1”. This will read 8 bytes (bs=8) once rather than infinitely (count=1) and exit, passing control to the next script command. You then place the “dd” command along with any output processing commands within a while loop to continuously process output till some flag is set or some other user interaction.
PS, by default DD will output a record count and some other diagnostic data along with the output. In this scenario this is unwanted data and to get rid of it you simply need to redirect stderr to dev null like so:
dd if=/dev/rfcomm0 bs=8 count=1 2> /dev/null