od.1p (26574B)
- '\" et
- .TH OD "1P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
- .\"
- .SH PROLOG
- This manual page is part of the POSIX Programmer's Manual.
- The Linux implementation of this interface may differ (consult
- the corresponding Linux manual page for details of Linux behavior),
- or the interface may not be implemented on Linux.
- .\"
- .SH NAME
- od
- \(em dump files in various formats
- .SH SYNOPSIS
- .LP
- .nf
- od \fB[\fR-v\fB] [\fR-A \fIaddress_base\fB] [\fR-j \fIskip\fB] [\fR-N \fIcount\fB] [\fR-t \fItype_string\fB]\fR...
- \fB[\fIfile\fR...\fB]\fR
- .P
- od \fB[\fR-bcdosx\fB] [\fIfile\fB] [[\fR+\fB]\fIoffset\fB[\fR.\fB][\fRb\fB]]\fR
- .fi
- .SH DESCRIPTION
- The
- .IR od
- utility shall write the contents of its input files to standard output
- in a user-specified format.
- .SH OPTIONS
- The
- .IR od
- utility shall conform to the Base Definitions volume of POSIX.1\(hy2017,
- .IR "Section 12.2" ", " "Utility Syntax Guidelines",
- except that the order of presentation of the
- .BR \-t
- options
- and the
- .BR \-bcdosx
- options
- is significant.
- .P
- The following options shall be supported:
- .IP "\fB\-A\ \fIaddress_base\fR" 10
- .br
- Specify the input offset base. See the EXTENDED DESCRIPTION section.
- The application shall ensure that the
- .IR address_base
- option-argument is a character. The characters
- .BR 'd' ,
- .BR 'o' ,
- and
- .BR 'x'
- specify that the offset base shall be written in decimal, octal, or
- hexadecimal, respectively. The character
- .BR 'n'
- specifies that the offset shall not be written.
- .IP "\fB\-b\fP" 10
- Interpret bytes in octal. This shall be equivalent to
- .BR "\-t\ o1" .
- .IP "\fB\-c\fP" 10
- Interpret bytes as characters specified by the current setting of the
- .IR LC_CTYPE
- category. Certain non-graphic characters appear as C escapes:
- .BR \(dqNUL=\e0\(dq ,
- .BR \(dqBS=\eb\(dq ,
- .BR \(dqFF=\ef\(dq ,
- .BR \(dqNL=\en\(dq ,
- .BR \(dqCR=\er\(dq ,
- .BR \(dqHT=\et\(dq ;
- others appear as 3-digit octal numbers.
- .IP "\fB\-d\fP" 10
- Interpret
- .IR word s
- (two-byte units) in unsigned decimal. This shall be equivalent to
- .BR "\-t\ u2" .
- .IP "\fB\-j\ \fIskip\fR" 10
- Jump over
- .IR skip
- bytes from the beginning of the input. The
- .IR od
- utility shall read or seek past the first
- .IR skip
- bytes in the concatenated input files. If the combined input is not at
- least
- .IR skip
- bytes long, the
- .IR od
- utility shall write a diagnostic message to standard error and exit
- with a non-zero exit status.
- .RS 10
- .P
- By default, the
- .IR skip
- option-argument shall be interpreted as a decimal number. With a
- leading 0x or 0X, the offset shall be interpreted as a hexadecimal
- number; otherwise, with a leading
- .BR '0' ,
- the offset shall be interpreted as an octal number. Appending the
- character
- .BR 'b' ,
- .BR 'k' ,
- or
- .BR 'm'
- to offset shall cause it to be interpreted as a multiple of 512,
- 1\|024, or 1\|048\|576 bytes, respectively. If the
- .IR skip
- number is hexadecimal, any appended
- .BR 'b'
- shall be considered to be the final hexadecimal digit.
- .RE
- .IP "\fB\-N\ \fIcount\fR" 10
- Format no more than
- .IR count
- bytes of input. By default,
- .IR count
- shall be interpreted as a decimal number. With a leading 0x or 0X,
- .IR count
- shall be interpreted as a hexadecimal number; otherwise, with a leading
- .BR '0' ,
- it shall be interpreted as an octal number. If
- .IR count
- bytes of input (after successfully skipping, if
- .BR \-j
- .IR skip
- is specified) are not available, it shall not be considered an error;
- the
- .IR od
- utility shall format the input that is available.
- .IP "\fB\-o\fP" 10
- Interpret
- .IR word s
- (two-byte units) in octal. This shall be equivalent to
- .BR "\-t\ o2" .
- .IP "\fB\-s\fP" 10
- Interpret
- .IR word s
- (two-byte units) in signed decimal. This shall be equivalent to
- .BR "\-t\ d2" .
- .IP "\fB\-t\ \fItype_string\fR" 10
- .br
- Specify one or more output types. See the EXTENDED DESCRIPTION
- section. The application shall ensure that the
- .IR type_string
- option-argument is a string specifying the types to be used when
- writing the input data. The string shall consist of the type
- specification characters
- .BR a ,
- .BR c ,
- .BR d ,
- .BR f ,
- .BR o ,
- .BR u ,
- and
- .BR x ,
- specifying named character, character, signed decimal, floating point,
- octal, unsigned decimal, and hexadecimal, respectively. The type
- specification characters
- .BR d ,
- .BR f ,
- .BR o ,
- .BR u ,
- and
- .BR 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
- .BR f
- can be followed by an optional
- .BR F ,
- .BR D ,
- or
- .BR L
- indicating that the conversion should be applied to an item of type
- .BR float ,
- .BR double ,
- or
- .BR "long double" ,
- respectively. The type specification characters
- .BR d ,
- .BR o ,
- .BR u ,
- and
- .BR x
- can be followed by an optional
- .BR C ,
- .BR S ,
- .BR I ,
- or
- .BR L
- indicating that the conversion should be applied to an item of type
- .BR char ,
- .BR short ,
- .BR int ,
- or
- .BR long ,
- respectively. Multiple types can be concatenated within the same
- .IR type_string
- and multiple
- .BR \-t
- options can be specified. Output lines shall be written for each type
- specified in the order in which the type specification characters are
- specified.
- .IP "\fB\-v\fP" 10
- Write all input data. Without the
- .BR \-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), shall be replaced with a line containing only an
- <asterisk>
- (\c
- .BR '*' ).
- .IP "\fB\-x\fP" 10
- Interpret
- .IR word s
- (two-byte units) in hexadecimal. This shall be equivalent to
- .BR "\-t\ x2" .
- .P
- Multiple types can be specified by using multiple
- .BR \-bcdostx
- options. Output lines are written for each type specified in the order
- in which the types are specified.
- .SH OPERANDS
- The following operands shall be supported:
- .IP "\fIfile\fR" 10
- A pathname of a file to be read. If no
- .IR file
- operands are specified, the standard input shall be used.
- .RS 10
- .P
- If there are no more than two operands, none of the
- .BR \-A ,
- .BR \-j ,
- .BR \-N ,
- .BR \-t ,
- or
- .BR \-v
- options is specified, and either of the following is true: the first
- character of the last operand is a
- <plus-sign>
- (\c
- .BR '\(pl' ),
- or there are two operands and the first character of the last operand
- is numeric;
- the last operand shall be interpreted as an offset operand on
- XSI-conformant systems.
- Under these conditions, the results are unspecified on systems that are
- not XSI-conformant systems.
- .RE
- .IP "\fB[+]\fIoffset\fB[.][b]\fR" 10
- The
- .IR offset
- operand specifies the offset in the file where dumping is to commence.
- This operand is normally interpreted as octal bytes. If
- .BR '.'
- is appended, the offset shall be interpreted in decimal. If
- .BR 'b'
- is appended, the offset shall be interpreted in units of 512 bytes.
- .SH STDIN
- The standard input shall be used if no
- .IR file
- operands are specified, and shall be used if a
- .IR file
- operand is
- .BR '\-'
- and the implementation treats the
- .BR '\-'
- as meaning standard input.
- Otherwise, the standard input shall not be used.
- See the INPUT FILES section.
- .SH "INPUT FILES"
- The input files can be any file type.
- .SH "ENVIRONMENT VARIABLES"
- The following environment variables shall affect the execution of
- .IR od :
- .IP "\fILANG\fP" 10
- Provide a default value for the internationalization variables that are
- unset or null. (See the Base Definitions volume of POSIX.1\(hy2017,
- .IR "Section 8.2" ", " "Internationalization Variables"
- for the precedence of internationalization variables used to determine
- the values of locale categories.)
- .IP "\fILC_ALL\fP" 10
- If set to a non-empty string value, override the values of all the
- other internationalization variables.
- .IP "\fILC_CTYPE\fP" 10
- Determine the locale for the interpretation of sequences of bytes of
- text data as characters (for example, single-byte as opposed to
- multi-byte characters in arguments and input files).
- .IP "\fILC_MESSAGES\fP" 10
- .br
- Determine the locale that should be used to affect the format and
- contents of diagnostic messages written to standard error.
- .IP "\fILC_NUMERIC\fP" 10
- .br
- Determine the locale for selecting the radix character used when
- writing floating-point formatted output.
- .IP "\fINLSPATH\fP" 10
- Determine the location of message catalogs for the processing of
- .IR LC_MESSAGES .
- .SH "ASYNCHRONOUS EVENTS"
- Default.
- .SH STDOUT
- See the EXTENDED DESCRIPTION section.
- .SH STDERR
- The standard error shall be used only for diagnostic messages.
- .SH "OUTPUT FILES"
- None.
- .SH "EXTENDED DESCRIPTION"
- The
- .IR od
- utility shall copy sequentially each input file to standard output,
- transforming the input data according to the output types specified by
- the
- .BR \-t
- option
- or the
- .BR \-bcdosx
- options.
- If no output type is specified, the default output shall be as if
- .BR "\-t\ oS"
- had been specified.
- .P
- The number of bytes transformed by the output type specifier
- .BR c
- may be variable depending on the
- .IR LC_CTYPE
- category.
- .P
- The default number of bytes transformed by output type specifiers
- .BR d ,
- .BR f ,
- .BR o ,
- .BR u ,
- and
- .BR x
- corresponds to the various C-language types as follows. If the
- .IR c99
- compiler is present on the system, these specifiers shall correspond to
- the sizes used by default in that compiler. Otherwise, these sizes
- may vary among systems that conform to POSIX.1\(hy2008.
- .IP " *" 4
- For the type specifier characters
- .BR d ,
- .BR o ,
- .BR u ,
- and
- .BR x ,
- the default number of bytes shall correspond to the size of the
- underlying implementation's basic integer type. For these specifier
- characters, the implementation shall support values of the optional
- number of bytes to be converted corresponding to the number of bytes in
- the C-language types
- .BR char ,
- .BR short ,
- .BR int ,
- and
- .BR long .
- These numbers can also be specified by an application as the characters
- .BR 'C' ,
- .BR 'S' ,
- .BR 'I' ,
- and
- .BR 'L' ,
- respectively. The implementation shall also support the values 1, 2, 4,
- and 8, even if it provides no C-Language types of those sizes. The
- implementation shall support the decimal value corresponding to the
- C-language type
- .BR "long long" .
- The byte order used when interpreting numeric values is
- implementation-defined, but shall correspond to the order in which a
- constant of the corresponding type is stored in memory on the system.
- .IP " *" 4
- For the type specifier character
- .BR f ,
- the default number of bytes shall correspond to the number of bytes in
- the underlying implementation's basic double precision floating-point
- data type. The implementation shall support values of the optional
- number of bytes to be converted corresponding to the number of bytes in
- the C-language types
- .BR float,
- .BR double ,
- and
- .BR "long double" .
- These numbers can also be specified by an application as the characters
- .BR 'F' ,
- .BR 'D' ,
- and
- .BR 'L' ,
- respectively.
- .P
- The type specifier character
- .BR a
- specifies that bytes shall be 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 shall be used for this type
- specification. Bytes with the values listed in the following table
- shall be written using the corresponding names for those characters.
- .br
- .sp
- .ce 1
- \fBTable: Named Characters in \fIod\fP\fR
- .TS
- center box tab(@);
- cB cB | cB cB | cB cB | cB cB
- l lb | l lb | l lb | l lb.
- Value@Name@Value@Name@Value@Name@Value@Name
- _
- \e000@nul@\e001@soh@\e002@stx@\e003@etx
- \e004@eot@\e005@enq@\e006@ack@\e007@bel
- \e010@bs@\e011@ht@\e012@lf \fRor\fP nl\u\s-3*\s+3\d@\e013@vt
- \e014@ff@\e015@cr@\e016@so@\e017@si
- \e020@dle@\e021@dc1@\e022@dc2@\e023@dc3
- \e024@dc4@\e025@nak@\e026@syn@\e027@etb
- \e030@can@\e031@em@\e032@sub@\e033@esc
- \e034@fs@\e035@gs@\e036@rs@\e037@us
- \e040@sp@\e177@del
- .TE
- .TP 10
- .BR Note:
- The
- .BR \(dq\e012\(dq
- value may be written either as
- .BR lf
- or
- .BR nl .
- .P
- .P
- The type specifier character
- .BR c
- specifies that bytes shall be interpreted as characters specified by
- the current setting of the
- .IR LC_CTYPE
- locale category. Characters listed in the table in the Base Definitions volume of POSIX.1\(hy2017,
- .IR "Chapter 5" ", " "File Format Notation"
- (\c
- .BR '\e\e' ,
- .BR '\ea' ,
- .BR '\eb' ,
- .BR '\ef' ,
- .BR '\en' ,
- .BR '\er' ,
- .BR '\et' ,
- .BR '\ev' )
- shall be written as the corresponding escape sequences, except that
- <backslash>
- shall be written as a single
- <backslash>
- and a NUL shall be written as
- .BR '\e0' .
- Other non-printable characters shall be written as one three-digit
- octal number for each byte in the character. Printable multi-byte
- characters shall be written in the area corresponding to the first byte
- of the character; the two-character sequence
- .BR \(dq**\(dq
- shall be written in the area corresponding to each remaining byte in
- the character, as an indication that the character is continued. When
- either the
- .BR \-j
- .IR skip
- or
- .BR \-N
- .IR count
- option is specified along with the
- .BR 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-defined.
- .P
- The input data shall be 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 shall 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 shall sequentially transform the parts
- of the input block, and the output from each of the transformations
- shall be separated by one or more
- <blank>
- characters.
- .P
- If, as a result of the specification of the
- .BR \-N
- option or end-of-file being reached on the last input file, input data
- only partially satisfies an output type, the input shall be extended
- sufficiently with null bytes to write the last byte of the input.
- .P
- Unless
- .BR "\-A\ n"
- is specified, the first output line produced for each input block shall
- 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 shall not contain any
- <blank>
- characters, shall start at the first character of the output line,
- and shall be followed by one or more
- <blank>
- characters. In addition, the offset of the byte following the last byte
- written shall be written after all the input data has been processed,
- but shall not be followed by any
- <blank>
- characters.
- .P
- If no
- .BR \-A
- option is specified, the input offset base is unspecified.
- .SH "EXIT STATUS"
- The following exit values shall be returned:
- .IP "\00" 6
- All input files were processed successfully.
- .IP >0 6
- An error occurred.
- .SH "CONSEQUENCES OF ERRORS"
- Default.
- .LP
- .IR "The following sections are informative."
- .SH "APPLICATION USAGE"
- XSI-conformant applications are warned not to use filenames starting
- with
- .BR '\(pl'
- 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
- .BR \-A ,
- .BR \-j ,
- or
- .BR \-N
- options. To guarantee that one of these filenames is always
- interpreted as a filename, an application could always specify the
- address base format with the
- .BR \-A
- option.
- .SH EXAMPLES
- If a file containing 128 bytes with decimal values zero to 127, in
- increasing order, is supplied as standard input to the command:
- .sp
- .RS 4
- .nf
- od -A d -t a
- .fi
- .P
- .RE
- .P
- on an implementation using an input block size of 16 bytes, the
- standard output, independent of the current locale setting, would be
- similar to:
- .sp
- .RS 4
- .nf
- 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 ! " # $ % & \(aq ( ) * + , - . /
- 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 [ \e ] \(ha _
- 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 { | } \(ti del
- 0000128
- .fi
- .P
- .RE
- .P
- Note that this volume of POSIX.1\(hy2017 allows
- .BR nl
- or
- .BR 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
- .BR lf
- (line feed), but traditional implementations have referred to this
- character as newline
- (\c
- .BR nl )
- and the POSIX locale character set symbolic name for the corresponding
- character is a
- <newline>.
- .P
- The command:
- .sp
- .RS 4
- .nf
- od -A o -t o2x2x -N 18
- .fi
- .P
- .RE
- .P
- 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:
- .sp
- .RS 4
- .nf
- 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
- .fi
- .P
- .RE
- .P
- The command:
- .sp
- .RS 4
- .nf
- od -A d -t f -t o4 -t x4 -N 24 -j 0x15
- .fi
- .P
- .RE
- .P
- on a system with 64-bit doubles (for example, IEEE\ Std\ 754\(hy1985 double
- precision floating-point format) would skip 21 bytes of input data and
- then write 24 bytes in approximately the following format:
- .sp
- .RS 4
- .nf
- 0000000 1.00000000000000e+00 1.57350000000000e+01
- 07774000000 00000000000 10013674121 35341217270
- 3ff00000 00000000 402f3851 eb851eb8
- 0000016 1.40668230000000e+02
- 10030312542 04370303230
- 40619562 23e18698
- 0000024
- .fi
- .P
- .RE
- .SH RATIONALE
- The
- .IR od
- utility went through several names in early proposals, including
- .IR hd ,
- .IR xd ,
- and most recently
- .IR hexdump .
- There were several objections to all of these based on the following
- reasons:
- .IP " *" 4
- The
- .IR hd
- and
- .IR xd
- names conflicted with historical utilities that behaved differently.
- .IP " *" 4
- The
- .IR hexdump
- description was much more complex than needed for a simple dump
- utility.
- .IP " *" 4
- The
- .IR od
- utility has been available on all historical implementations and there
- was no need to create a new name for a utility so similar to the
- historical
- .IR od
- utility.
- .P
- The original reasons for not standardizing historical
- .IR od
- were also fairly widespread. Those reasons are given below along with
- rationale explaining why the standard developers believe that this
- version does not suffer from the indicated problem:
- .IP " *" 4
- The BSD and System V versions of
- .IR od
- have diverged, and the intersection of features provided by both does
- not meet the needs of the user community. In fact, the System V
- version only provides a mechanism for dumping octal bytes and
- .BR short s,
- signed and unsigned decimal
- .BR short s,
- hexadecimal
- .BR short s,
- and ASCII characters. BSD added the ability to dump
- .BR float s,
- .BR double s,
- named ASCII characters, and octal, signed decimal, unsigned decimal,
- and hexadecimal
- .BR long s.
- The version presented here provides more normalized forms for dumping
- bytes,
- .BR short s,
- .BR int s,
- and
- .BR long s
- in octal, signed decimal, unsigned decimal, and hexadecimal;
- .BR float ,
- .BR double ,
- and
- .BR "long double" ;
- and named ASCII as well as current locale characters.
- .IP " *" 4
- It would not be possible to come up with a compatible superset of the
- BSD and System V flags that met the requirements of the standard
- developers. The historical default
- .IR od
- output is the specified default output of this utility. None of the
- option letters chosen for this version of
- .IR od
- conflict with any of the options to historical versions of
- .IR od .
- .IP " *" 4
- On systems with different sizes for
- .BR short ,
- .BR int ,
- and
- .BR long ,
- there was no way to ask for dumps of
- .BR int s,
- even in the BSD version. Because of the way options are named, the
- name space could not be extended to solve these problems. This is why
- the
- .BR \-t
- option was added (with type specifiers more closely matched to the
- \fIprintf\fR()
- formats used in the rest of this volume of POSIX.1\(hy2017) and the optional field sizes were
- added to the
- .BR d ,
- .BR f ,
- .BR o ,
- .BR u ,
- and
- .BR x
- type specifiers. It is also one of the reasons why the historical
- practice was not mandated as a required obsolescent form of
- .IR od .
- (Although the old versions of
- .IR od
- are not listed as an obsolescent form, implementations are urged to
- continue to recognize the older forms for several more years.) The
- .BR a ,
- .BR c ,
- .BR f ,
- .BR o ,
- and
- .BR x
- types match the meaning of the corresponding format characters in the
- historical implementations of
- .IR od
- except for the default sizes of the fields converted. The
- .BR d
- format is signed in this volume of POSIX.1\(hy2017 to match the
- \fIprintf\fR()
- notation. (Historical versions of
- .IR od
- used
- .BR d
- as a synonym for
- .BR u
- in this version. The System V implementation uses
- .BR s
- for signed decimal; BSD uses
- .BR i
- for signed decimal and
- .BR s
- for null-terminated strings.) Other than
- .BR d
- and
- .BR u ,
- all of the type specifiers match format characters in the historical
- BSD version of
- .BR od .
- .RS 4
- .P
- The sizes of the C-language types
- .BR char ,
- .BR short ,
- .BR int ,
- .BR long ,
- .BR float ,
- .BR double ,
- and
- .BR "long double"
- are used even though it is recognized that there may be zero or more
- than one compiler for the C language on an implementation and that they
- may use different sizes for some of these types. (For example, one
- compiler might use 2 bytes
- .BR short s,
- 2 bytes
- .BR int s,
- and 4 bytes
- .BR long s,
- while another compiler (or an option to the same compiler) uses 2 bytes
- .BR short s,
- 4 bytes
- .BR int s,
- and 4 bytes
- .BR long s.)
- Nonetheless, there has to be a basic size known by the implementation
- for these types, corresponding to the values reported by invocations of
- the
- .IR getconf
- utility when called with
- .IR system_var
- operands
- {UCHAR_MAX},
- {USHORT_MAX},
- {UINT_MAX},
- and
- {ULONG_MAX}
- for the types
- .BR char ,
- .BR short ,
- .BR int ,
- and
- .BR long ,
- respectively. There are similar constants required by the ISO\ C standard, but
- not required by the System Interfaces volume of POSIX.1\(hy2017 or this volume of POSIX.1\(hy2017. They are
- {FLT_MANT_DIG},
- {DBL_MANT_DIG},
- and
- {LDBL_MANT_DIG}
- for the types
- .BR float ,
- .BR double ,
- and
- .BR "long double" ,
- respectively. If the optional
- .IR c99
- utility is provided by the implementation and used as specified by
- \&this volume of POSIX.1\(hy2017, these are the sizes that would be provided. If an option is used
- that specifies different sizes for these types, there is no guarantee
- that the
- .IR od
- utility is able to interpret binary data output by such a program
- correctly.
- .P
- This volume of POSIX.1\(hy2017 requires that the numeric values of these lengths be recognized
- by the
- .IR od
- utility and that symbolic forms also be recognized. Thus, a conforming
- application can always look at an array of
- .BR "unsigned long"
- data elements using
- .IR od
- .BR \-t
- .IR uL .
- .RE
- .IP " *" 4
- The method of specifying the format for the address field based on
- specifying a starting offset in a file unnecessarily tied the two
- together. The
- .BR \-A
- option now specifies the address base and the
- .BR \-S
- option specifies a starting offset.
- .IP " *" 4
- It would be difficult to break the dependence on US ASCII to achieve
- an internationalized utility. It does not seem to be any harder for
- .IR od
- to dump characters in the current locale than it is for the
- .IR ed
- or
- .IR sed
- .BR l
- commands. The
- .BR c
- type specifier does this without difficulty and is completely
- compatible with the historical implementations of the
- .BR c
- format character when the current locale uses a superset of the ISO/IEC\ 646:\|1991 standard
- as a codeset. The
- .BR a
- type specifier (from the BSD
- .BR a
- format character) was left as a portable means to dump ASCII (or more
- correctly ISO/IEC\ 646:\|1991 standard (IRV)) so that headers produced by
- .IR pax
- could be deciphered even on systems that do not use the ISO/IEC\ 646:\|1991 standard as a
- subset of their base codeset.
- .P
- The use of
- .BR \(dq**\(dq
- as an indication of continuation of a multi-byte character in
- .BR c
- specifier output was chosen based on seeing an implementation that uses
- this method. The continuation bytes have to be marked in a way that is
- not ambiguous with another single-byte or multi-byte character.
- .P
- An early proposal used
- .BR \-S
- and
- .BR \-n ,
- respectively, for the
- .BR \-j
- and
- .BR \-N
- options eventually selected. These were changed to avoid conflicts with
- historical implementations.
- .P
- The original standard specified
- .BR "\-t o2"
- as the default when no output type was given. This was changed to
- .BR "\-t oS"
- (the length of a
- .BR short )
- to accommodate a supercomputer implementation that historically used 64
- bits as its default (and that defined shorts as 64 bits). This change
- should not affect conforming applications. The requirement to support
- lengths of 1, 2, and 4 was added at the same time to address an
- historical implementation that had no two-byte data types in its C
- compiler.
- .P
- The use of a basic integer data type is intended to allow the
- implementation to choose a word size commonly used by applications
- on that architecture.
- .P
- Earlier versions of this standard allowed for implementations with
- bytes other than eight bits, but this has been modified in this
- version.
- .SH "FUTURE DIRECTIONS"
- All option and operand interfaces marked XSI may be removed
- in a future version.
- .SH "SEE ALSO"
- .IR "\fIc99\fR\^",
- .IR "\fIsed\fR\^"
- .P
- The Base Definitions volume of POSIX.1\(hy2017,
- .IR "Chapter 5" ", " "File Format Notation",
- .IR "Chapter 8" ", " "Environment Variables",
- .IR "Section 12.2" ", " "Utility Syntax Guidelines"
- .\"
- .SH COPYRIGHT
- Portions of this text are reprinted and reproduced in electronic form
- from IEEE Std 1003.1-2017, Standard for Information Technology
- -- Portable Operating System Interface (POSIX), The Open Group Base
- Specifications Issue 7, 2018 Edition,
- Copyright (C) 2018 by the Institute of
- Electrical and Electronics Engineers, Inc and The Open Group.
- In the event of any discrepancy between this version and the original IEEE and
- The Open Group Standard, the original IEEE and The Open Group Standard
- is the referee document. The original Standard can be obtained online at
- http://www.opengroup.org/unix/online.html .
- .PP
- Any typographical or formatting errors that appear
- in this page are most likely
- to have been introduced during the conversion of the source files to
- man page format. To report such errors, see
- https://www.kernel.org/doc/man-pages/reporting_bugs.html .