Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I recently realized we can use cat as much as dd, and it's actually faster than dd

I know that dd was useful in dealing with tapes where block size actually mattered in correctness, not just performance. In these days, though, are there situations where dd can do something cat can't? (Here I would regard a less than 20% performance difference irrelevant.)

Concrete examples would be nice!

share|improve this question
    
See this SO question for one concrete example. –  camh May 4 '11 at 6:02

7 Answers 7

up vote 81 down vote accepted

In appearance, dd is a tool from an IBM operating system that's retained its foreign appearance (its parameter passing), which performs some very rarely-used functions (such as EBCDIC to ASCII conversions or endianness reversal… not a common need nowadays).

I used to think that dd was faster for copying large blocks of data on the same disk (due to more efficient use of buffering), but this isn't true, at least on today's Linux systems.

I think some of dd's options are useful when deadling with tapes, where reading is really performed in blocks (tape drivers don't hide the blocks on the storage medium the way disk drivers do). But I don't know the specifics.

One thing dd can do that can't (easily) be done by any other POSIX tool is taking the first N bytes of a stream. Many systems can do it with head -c 42, but head -c, while common, isn't in POSIX (and ins't available today on e.g. OpenBSD). (tail -c is POSIX.) Also, even where head -c exists, it might read too many bytes from the source (because it uses stdio buffering internally), which is a problem if you're reading from a special file where just reading has an effect. (Current GNU coreutils read the exact count with head -c, but FreeBSD and NetBSD use stdio.)

More generally, dd gives an interface to the underlying file API that is unique amongst Unix tools: only dd can overwrite or truncate a file at any point or seek in a file. (This is dd's unique ability, and it's a big one; oddly enough dd is best known for things that other tools can do.)

  • Most Unix tools overwrite their output file, i.e. erase its contents and start it over from scratch. This is what happens when you use > redirection in the shell as well.
  • You can append to a file's contents with >> redirection in the shell, or with tee -a.
  • If you want to shorten a file by removing all data after a certain point, this is supported by the underlying kernel and C API through the truncate function, but not exposed by any command line tool except dd:

    dd if=/dev/null of=/file/to/truncate seek=1 bs=123456  # truncate file to 123456 bytes
    
  • If you want to overwrite data in the middle of a file, again, this is possible in the underyling API by opening the file for writing without truncating (and calling lseek to move to the desired position if necessary), but only dd can open a file without truncating or appending, or seek from the shell (more complex example).

    # zero out the second kB block in the file (i.e. bytes 1024 to 2047)
    dd if=/dev/zero of=/path/to/file bs=1024 seek=1 count=1 conv=notrunc
    

So… As a system tool, dd is pretty much useless. As a text (or binary file) processing tool, it's quite valuable!

share|improve this answer
2  
+1 - Thank you very much for this interesting answer! –  boehj May 3 '11 at 16:11
    
Accepted because I think it explains the gist of the other answers (trunc and seek being usable from dd). –  kizzx2 May 4 '11 at 13:01
    
One more special use: dd can read binary data from nonseekable file descriptors without potentially destroying unread data due to stdio buffering. See here for an example: etalabs.net/sh_tricks.html –  R.. May 7 '11 at 2:11
    
@R..: Good point. While the GNU implementation is safe, others aren't. –  Gilles May 7 '11 at 10:42
1  
@R..: Yes. In GNU coreutils 6.10, head -c N calls read and never goes beyond N. In NetBSD 5.1, head -c calls getc. In FreeBSD 7.4, head -c calls fread. –  Gilles May 7 '11 at 12:29

The dd command includes LOTS of options that cat is not able to accommodate. Perhaps in your usage cases cat is a workable substitute, but it is not a dd replacement.

One example would be using dd to copy part of something but not the whole thing. Perhaps you want to rip out some of the bits from the middle of an iso image or the partition table from a hard drive based on a known location on the device. With dd you can specify the start, stop and quantity options that allow these actions.

These options of dd make it indispensable for fine grained data manipulation whereas cat* can only operate on whole file objects, devices or streams.

*As noted by Gilles in the comments, it is possible to combine cat with other tools to isolate parts of something, but cat still operates on the whole object.

share|improve this answer
2  
dd actually has nothing to do with low-level devices, it needs an entry in /dev like the others. You can copy a whole partition with cat, or a part of it with tail +c $(($start+1)) | head -c $count. –  Gilles May 3 '11 at 15:18
8  
Of course. ;-) And when I feed a 1.6TB disk image into cat | head | tail to fetch the last few MBs the disk spin up will suck the moon in closer to earth. –  Caleb May 3 '11 at 17:01
1  
@Gilles Sorry I did mean to acknowledge that my use of the term "low level" wasn't very good diction, although I was referring to data on devices, not devices. Perhaps "fine tuned data manipulation" would be better than "manipulating low level data". –  Caleb May 4 '11 at 13:09
    
@Caleb, your cat | head | tail example doesn't make sense. Firstly head will close stdin once it has fetched what it is going to fetch, so the cat will have a write failure and stop reading. Secondly, the cat is superfluous there, you could feed the disk image directly to head. –  jmtd May 7 '11 at 10:57
    
@jmtd, you missed the point. I was poking fun at @Gilles suggestion exactly because it didn't make sense to do it that way! Also, head closing stdin after it gets what it wants is useless in the case I gave of wanting something near the end, and feeding the disk image directly to head won't make that any less painful! –  Caleb May 7 '11 at 11:03

No one has yet mentioned that you can use dd to create sparse files, though truncate can also be used for the same purpose.

dd if=/dev/zero of=sparse-file bs=1 count=1 seek=10GB

This is almost instant and creates an arbitrary large file that can be used as a loopback file for instance:

loop=`losetup --show -f sparse-file`
mkfs.ext4 $loop
mkdir myloop
mount $loop myloop

The nice thing is that it initially only uses a single block of diskspace, and thereafter grows only as needed (ext4 formatting of a 10GB file consumes 291 MB on my system). Use du to see how much disk space is actually used -- ls reports only the maximum size the file may grow to.

share|improve this answer
2  
ls -ls shows you the sparse size. –  jmtd May 7 '11 at 10:58
    
Your command writes a useless byte to the file. dd of=sparse-file bs=1 count=0 seek=10G would be equivalent to truncate -s 10GB sparse-file. Confusingly enough, truncate and dd have exact opposite interpretation of GB vs. G... –  frostschutz Feb 8 '13 at 2:49
2  
@frostschutz: man dd says: MB =1000*1000, M =1024*1024 and so on. And man truncate says: MB 1000*1000, M 1024*1024, so there is no difference. I use both dd and truncate from the GNU coreutils. You should do so, too! :-) –  erik Jun 6 '13 at 9:20
    
@erik: Thanks for the correction. If it wasn't changed recently I must've confused it with something else somehow. –  frostschutz Jun 6 '13 at 16:05

Override specific segments of a hard-drive with something is a common example. For example you might want to delete your MBR using this command:

dd if=/dev/zero of=/dev/sda bs=446 count=1

Also you can create empty files with it (say for loop disk images):

dd if=/dev/zero of=10mb.file bs=1024k count=10

share|improve this answer
    
As an aside, that second command is the fastest way that I know of to use up 10MB –  Kevin M May 3 '11 at 14:44
3  
@Kevin: Faster than head -c? Please share a benchmark! –  Gilles May 3 '11 at 15:15

dd is very useful for backing up the boot sector of a hard drive or other storage device (dd if=/dev/sda of=boot_sector.bin bs=512 count=1 ) and then later rewriting it (dd if=boot_sector.bin of=/dev/sda). It is similarly useful for backing up the headers of encrypted volumes.

cat might be able to be twisted into doing that but I wouldn't trust it on the rewriting part. It's difficult to get cat to only read/write a certain number of bytes.

share|improve this answer

I recently had had cause to clone some multiple-100s-of-GB partitions for the first time in my linuxing history (c.f cp -ar or rsync which have served me well many times). Of course I turned to dd 'cos everyone knows that's what you use... and was appalled by the performance. A bit of googling soon led me to ddrescue, which I've used a few times now and works superbly well (much faster than dd).

share|improve this answer

Here are some dd tricks I've come up with over the years..

Cut-and-Paste on unfriendly tty or non-interactive mode bash

If you're in a situation where EOF/^D/^F is not detected you can use dd to transfer text files to a host. Since it will stop reading after a specified amount of bytes automatically.

I used this as recently as last year during a security exercise where we were able to get non-tty shells on a remote host and needed to transfer files in.

In fact, I even did a couple binary files by base64 encoding them and using a slow, but reliable pure-bash base64 decoding script.

dd of=textfile.txt bs=1 count=<size_of_data_in_paste_buffer>

A super cool trick is that while dd is running, if you send it a USR1 signal, it will emit it's current status (bytes read, bytes per second..)

Universal throughput state filter

I wrote this to act as a pure bash progress filter for any program that emits data through stdout. (Note: Pretty much anything will emit data through stdout - for programs that don't, you can cheat if they don't barf on you using /dev/stdout as a filename. But the idea is basically, every time you get X amount of bytes, print hash marks (like old school FTP when you had hash mode on)

(Note) The progress file thing is lame, this was mostly a proof of concept. If I redid it, I'd just use a variable.

 dd bs=$BLKSZ of=${TMPFILE} 2>&1 \
                | grep --line-buffered -E '[[:digit:]]* bytes' \
                | awk '{ print $1 }' >> ${PROGRESS} &

 while [[ $(pidof dd) -gt 1 ]]; do

        # PROTIP: You can sleep partial seconds
        sleep .5

        # Force dd to update us on it's progress (which gets
        # redirected to $PROGRESS file.    
        pkill -USR1 dd
        local BYTES_THIS_CYCLE=$(tail -1 $PROGRESS)
        local XFER_BLKS=$(((BYTES_THIS_CYCLE-BYTES_LAST_CYCLE)/BLKSZ))

        if [ $XFER_BLKS -gt 0 ]; then
                printf "#%0.s" $(seq 0 $XFER_BLKS)
                BYTES_LAST_CYCLE=$BYTES_THIS_CYCLE
        fi
done

slice-and-dice files using anonymous shell filehandles

Here's an extremely pseudo-code example of how you can have a signed tar file that you can extract without errors by providing tar input through an anonymous filehandle - without using any tmp files to store partial file data.

generate_hash() {
    echo "yay!"
}

# Create a tar file, generate a hash, append it to the end
tar -cf log.tar /var/log/* 2>/dev/null
TARFILE_SIZE=$(stat -f "%z" log.tar)
SIGNATURE=$(generate_hash log.tar)
echo $SIGNATURE >>log.tar

# Then, later, extract without getting an error..

tar xvf <(dd if=$OLDPWD/log.tar bs=1 count=${TARFILE_SIZE})

The tl;dr is: I find dd to be incredibly useful. And these are just the three examples I can think of off the top of my head.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.