OD(1) General Commands Manual OD(1)

od — dump files in various formats

od [-v][-A address_base][-j skip][-N count][-t type_string]... [file ...]

od [-bcdosx][file] [[+]offset[file ....][b]file ...]

The od utility will write the contents of its input files to standard output in a user-specified format.

The od utility supports the XBD specification, , except that the order of presentation of the -t options and the -bcdosx options is significant.

The following options are supported:

Specify the input offset base (see the EXTENDED DESCRIPTION section). The address_base option-argument must be a character. The characters d, o and x specify that the offset base will be written in decimal, octal or hexadecimal, respectively. The character n specifies that the offset will not be written.
Interpret bytes in octal. This is equivalent to t -o1 .
Interpret bytes as characters specified by the current setting of the LC_CTYPE category. Certain non-graphic characters appear as C escapes: NUL= \0 , BS= \b , FF= \f , NL= \n , CR= \r , HT= \t ; others appear as 3-digit octal numbers.
Interpret word s (two-byte units) in unsigned decimal. This is equivalent to t -u2 .
Jump over skip bytes from the beginning of the input. The od utility will read or seek past the first skip bytes in the concatenated input files. If the combined input is not at least skip bytes long, the od utility will write a diagnostic message to standard error and exit with a non-zero exit status. By default, the skip option-argument is interpreted as a decimal number. With a leading 0x or 0X, the offset is interpreted as a hexadecimal number; otherwise, with a leading 0, the offset will be interpreted as an octal number. Appending the character b, k or m to offset will cause it to be interpreted as a multiple of 512, 1024 or 1048576 bytes, respectively. If the skip number is hexadecimal, any appended b is considered to be the final hexadecimal digit.
Format no more than count bytes of input. By default, count is interpreted as a decimal number. With a leading 0x or 0X, count is interpreted as a hexadecimal number; otherwise, with a leading 0, it is interpreted as an octal number. If count bytes of input (after successfully skipping, if -j skip is specified) are not available, it will not be considered an error; the od utility will format the input that is available.
Interpret word s (two-byte units) in octal. This is equivalent to t -o2 .
Interpret word s (two-byte units) in signed decimal. This is equivalent to t -d2 .
Specify one or more output types (see the EXTENDED DESCRIPTION section). The type_string option-argument must be a string specifying the types to be used when writing the input data. The string must consist of the type specification characters a, c, d, f, o, u and x, specifying named character, character, signed decimal, floating point, octal, unsigned decimal and hexadecimal, respectively. The type specification characters d, f, o, u and x can be followed by an optional unsigned decimal integer that specifies the number of bytes to be transformed by each instance of the output type. The type specification character f can be followed by an optional F, D or L indicating that the conversion should be applied to an item of type float , double or long double , respectively. The type specification characters d, o, u and x can be followed by an optional C, S, I or L indicating that the conversion should be applied to an item of type char , short , int or long , respectively. Multiple types can be concatenated within the same type_string and multiple -t options can be specified. Output lines are written for each type specified in the order in which the type specification characters are specified.
Write all input data. Without the -v option, any number of groups of output lines, which would be identical to the immediately preceding group of output lines (except for the byte offsets), will be replaced with a line containing only an asterisk (*).
Interpret word s (two-byte units) in hexadecimal. This is equivalent to t -x2 .

Multiple types can be specified by using multiple -bcdostx options. Output lines are written for each type specified in the order in which the types are specified.

The following operands are supported:

file
A pathname of a file to be written. If no file operands are specified, the standard input will be used. If the first character of file is a plus sign (+) or the first character of the first file operand is numeric, no more than two operands are given, and none of the -A , -j , -N or -t options is specified, the operand is assumed to be an offset .
The offset operand specifies the offset in the file where dumping is to commence. This operand is normally interpreted as octal bytes. If . is appended, the offset is interpreted in decimal. If b is appended, the offset is interpreted in units of 512 bytes. If the file argument is omitted, and none of the -A , -j , -N or -t options is specified, the offset argument must be preceded by +.

The standard input is used only if no file operands are specified. See the INPUT FILES section.

The input files can be any file type.

The following environment variables affect the execution of od :

Provide a default value for the internationalisation variables that are unset or null. If LANG is unset or null, the corresponding value from the implementation-dependent default locale will be used. If any of the internationalisation variables contains an invalid setting, the utility will behave as if none of the variables had been defined.
If set to a non-empty string value, override the values of all the other internationalisation variables.
Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single- as opposed to multi-byte characters in arguments and input files).
Determine the locale that should be used to affect the format and contents of diagnostic messages written to standard error.
Determine the locale for selecting the radix character used when writing floating-point formatted output.
Determine the location of message catalogues for the processing of LC_MESSAGES .

Default.

See the EXTENDED DESCRIPTION section.

Used only for diagnostic messages.

None.

The od utility copies sequentially each input file to standard output, transforming the input data according to the output types specified by the -t options or the -bcdosx options. If no output type is specified, the default output is as if -t o2 had been specified.

The number of bytes transformed by the output type specifier c may be variable depending on the LC_CTYPE category.

The default number of bytes transformed by output type specifiers d, f, o, u and x will correspond to the various C-language types as follows. If the compiler is present on the system, these specifiers will correspond to the sizes used by default in that compiler. Otherwise, these sizes are implementation-dependent.

  • For the type specifier characters d, o, u and x, the default number of bytes will correspond to the size of the underlying implementation's basic integral data type. For these specifier characters, the implementation will support values of the optional number of bytes to be converted corresponding to the number of bytes in the C-language types char , short , int and long. These numbers can also be specified by an application as the characters C, S, I and L, respectively. The byte order used when interpreting numeric values is implementation-dependent, but will correspond to the order in which a constant of the corresponding type is stored in memory on the system.
  • For the type specifier character f, the default number of bytes will correspond to the number of bytes in the underlying implementation's basic double precision floating-point data type. The implementation will support values of the optional number of bytes to be converted corresponding to the number of bytes in the C-language types float, double and long double . These numbers can also be specified by an application as the characters F, D and L, respectively.

The type specifier character a specifies that bytes are interpreted as named characters from the International Reference Version (IRV) of the ISO/IEC 646:1991 standard. Only the least significant seven bits of each byte will be used for this type specification. Bytes with the values listed in the following table will be written using the corresponding names for those characters.

Value Name Value Name Value Name Value Name
\000 nul \001 soh \002 stx \003 etx
\004 eot \005 enq \006 ack \007 bel
\010 bs \011 ht \012 lf or nl* \013 vt
\014 ff \015 cr \016 so \017 si
\020 dle \021 dc1 \022 dc2 \023 dc3
\024 dc4 \025 nak \026 syn \027 etb
\030 can \031 em \032 sub \033 esc
\034 fs \035 gs \036 rs \037 us
\040 sp \177 del

The \012 value may be written either as lf or nl .

The type specifier character c specifies that bytes will be interpreted as characters specified by the current setting of the LC_CTYPE locale category. Characters listed in the table in the specification, notation(7) (\\, \a, \b, \f, \n, \r, \t, \v) will be written as the corresponding escape sequences, except that backslash will be written as a single backslash and a NUL will be written as \0. Other non-printable characters will be written as one three-digit octal number for each byte in the character. If the size of a byte on the system is greater than nine bits, the format used for non-printable characters is implementation-dependent. Printable multi-byte characters will be written in the area corresponding to the first byte of the character; the two-character sequence ** will be written in the area corresponding to each remaining byte in the character, as an indication that the character is continued. When either the -j or -N option is specified along with the c type specifier, and this results in an attempt to start or finish in the middle of a multi-byte character, the result is implementation-dependent.

The input data is manipulated in blocks, where a block is defined as a multiple of the least common multiple of the number of bytes transformed by the specified output types. If the least common multiple is greater than 16, the results are unspecified. Each input block will be written as transformed by each output type, one per written line, in the order that the output types were specified. If the input block size is larger than the number of bytes transformed by the output type, the output type will sequentially transform the parts of the input block, and the output from each of the transformations will be separated by one or more blank characters.

If, as a result of the specification of the -N option or end-of-file being reached on the last input file, input data only partially satisfies an output type, the input will be extended sufficiently with null bytes to write the last byte of the input.

Unless -A n is specified, the first output line produced for each input block will be preceded by the input offset, cumulative across input files, of the next byte to be written. The format of the input offset is unspecified; however, it will not contain any blank characters, will start at the first character of the output line, and will be followed by one or more blank characters. In addition, the offset of the byte following the last byte written will be written after all the input data has been processed, but will not be followed by any blank characters.

If no -A option is specified, the input offset base is unspecified.

The following exit values are returned:

All input files were processed successfully.
An error occurred.

Default.

Applications are warned not to use filenames starting with + or a first operand starting with a numeric character so that the old functionality can be maintained by implementations, unless they specify one of the new options specified by the ISO/IEC 9945-2:1993 (“POSIX.2”) standard. To guarantee that one of these filenames will always be interpreted as a filename, an application could always specify the address base format with the -A option.

If a file containing 128 bytes with decimal values zero to 127, in increasing order, is supplied as standard input to the command:

od -A d -t a
on an implementation using an input block size of 16 bytes, the standard output, independent of the current locale setting, would be similar to: 
0000000 nul soh stx etx eot enq ack bel  bs  ht  nl  vt  ff  cr  so  si
0000016 dle dc1 dc2 dc3 dc4 nak syn etb can  em sub esc  fs  gs  rs  us
0000032  sp   !   "   #   $   %   &   '   (   )   *   +   ,   -   .   /
0000048   0   1   2   3   4   5   6   7   8   9   :   ;   <   =   >   ?
0000064   @   A   B   C   D   E   F   G   H   I   J   K   L   M   N   O
0000080   P   Q   R   S   T   U   V   W   X   Y   Z   [   \   ]   ^   _
0000096   `   a   b   c   d   e   f   g   h   i   j   k   l   m   n   o
0000112   p   q   r   s   t   u   v   w   x   y   z   {   |   }   ~ del
0000128

Note that this specification allows or lf to be used as the name for the ISO/IEC 646:1991 standard IRV character with decimal value 10. The IRV names this character lf (line feed), but traditional implementations have referred to this character as newline (nl) and the POSIX locale character set symbolic name for the corresponding character is a newline character.

The command: od -A o -t o2x2x -n 18 on a system with 32-bit words and an implementation using an input block size of 16 bytes could write 18 bytes in approximately the following format: 0000000 032056 031440 041123 042040 052516 044530 020043 031464 342e 3320 4253 4420 554e 4958 2023 3334 342e3320 42534420 554e4958 20233334 0000020 032472 353a 353a0000 0000022

The command: od -A d -t f -t o4 -t x4 -n 24 -j 0x15 on a system with 64-bit doubles (for example, the IEEE Std. 754 double precision floating-point format) would skip 21 bytes of input data and then write 24 bytes in approximately the following format: 0000000 1.00000000000000e+00 1.57350000000000e+01 07774000000 00000000000 10013674121 35341217270 3ff00000 00000000 402f3851 eb851eb8 0000016 1.40668230000000e+02 10030312542 04370303230 40619562 23e18698 0000024

All option and operand interfaces marked as extensions may be withdrawn in a future issue.

The IEEE PASC 1003.2 Interpretations Committee has forwarded concerns about parts of this interface definition to the IEEE PASC 1003.2 Interpretations Committee which is identifying the corrections. A future revision of this specification will align with IEEE Std. 1003.2b when finalised.

sed(1) .

February 1997 posix.fail