I am fairly new to unix and am having trouble understanding what some of the commands do.For example, when I use xxd on a ppm file (i.e. xxd image.ppm) I get an output like this:

00000000: 5036 0a31 3131 2031 3332 0a32 3535 0a55  P6.111 132.255.U
00000010: 6137 5966 3958 6939 566a 3953 6739 5464  a7Yf9Xi9Vj9Sg9Td
00000020: 3b57 643a 5763 3654 6335 5161 334e 5c30  ;Wd:Wc6Tc5Qa3N\0
00000030: 4f5a 3250 5d35 5361 3556 6334 5561 3352  OZ2P]5Sa5Vc4Ua3R
00000040: 5e32 515d 3256 6035 5b64 3856 6136 4a55  ^2Q]2V`5[d8Va6JU

Can someone please explain to me what this output represents?

| improve this question | | | | |
  • 2
    to find out what a command does, read its man page...don't just randomly run it - in many/most cases, that will be harmless. in some cases, it could alter or even wipe your input file. or much worse. e.g. run man xxd to find out what xxd does. – cas Feb 4 '18 at 16:46
  • @cas, though, the man page for xxd doesn't really describe what the output is, it just assumes the user knows what a common hexdump looks like :) – ilkkachu Feb 4 '18 at 16:49
  • True, but "hexdump" is such a basic, well-known term that it's self-explanatory. or should be :-). BTW, I generally use hexdump -C or hd rather than xxd - more flexible output options and, IMO, better documented. – cas Feb 4 '18 at 16:54
  • hexdump is probably not self-explanatory but it can be looked up. – Michael Le Barbier Grünewald Feb 4 '18 at 18:24
  • That what I miss most from my Ultrix days; man had examples of commands. – Rui F Ribeiro Feb 4 '18 at 23:14

The three parts are the offset from the start of the input, in hex; the data in hex; and the data in characters, if they're printable. 16 bytes to a line, since it's a nice round number and fits nicely on a screen.

A display like that is very often used in cases where both the binary and the textual data may be important. E.g. tcpdump -X uses a similar one.

On your first line:

00000000: 5036 0a31 3131 2031 3332 0a32 3535 0a55  P6.111 132.255.U

The offset 00000000 is zero, since this is the beginning; 50, 36, and 0a are the character codes for P, 6, and the newline, and so on. Unprintable characters are printed as dots on the right hand column.

Note that in some variants, the bytes in the middle section may be "inverted" within each group. This happens if the program interprets the input as little-endian numbers, and displays them as such, instead of as individual bytes concatenated.

xxd -e does exactly this. Consider:

$ printf  "ABCD" | xxd -e -g2 
00000000: 4241 4443                                ABCD

41 for A, and 42 for B appear in an inverted order, as well as the two others. od from GNU coreutils also inverts the bytes within the groups. When in doubt, double-check, or aim to get a one-by-one grouping. (compare e.g. od -x and od -tx1 in this.)

Of course, the meaning of the data itself can be found out from the documentation for the ppm format. My system has the man page ppm(5). (the online version on die.net has broken formatting.)

From that first line we can tell it's an RGB picture of size 111x132 pixels with 8-bits per sample.

| improve this answer | | | | |
  • 1
    +1 for referencing the ppm man page. i was too lazy :) – cas Feb 4 '18 at 16:48

It's a hex dump, in a fairly common hexdump format, with each line of output containing the byte offset (in hexadecimal*), hex digits for 16 bytes, and the ASCII representation of those same bytes.

* Note how the byte offset increments by 0x10 hex (16 decimal) for each line.

From man xxd:


   xxd - make a hexdump or do the reverse.


   xxd -h[elp]
   xxd [options] [infile [outfile]]
   xxd -r[evert] [options] [infile [outfile]]


xxd creates a hex dump of a given file or standard input. It can also convert a hex dump back to its original binary form. Like uuencode(1) and uudecode(1) it allows the transmission of binary data in a 'mail-safe' ASCII representation, but has the advantage of decoding to standard output. Moreover, it can be used to perform binary file patching. [...]

hex dumps are extremely useful when you need to know exactly which bytes are in a file at some exact location. They can help to diagnose problems where, for example, there are unexpected bytes (e.g. NULs (0x00) or carriage-returns (0x0D)) in the file and, as @ilkkachu mentions in his answer if the binary file format is documented (or you happen to know it anyway), it is often possible to interpret specific meanings for bytes in specific offsets (locations).

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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