OD(1)                      POSIX Programmer's Manual                     OD(1)



PPRROOLLOOGG
       This manual page is part of the POSIX Programmer's Manual.  The OS
       implementation of this interface may differ (consult the corresponding
       OS manual page for details of OS behavior), or the interface may not be
       implemented on OS.

NNAAMMEE
       od -- dump files in various formats

SSYYNNOOPPSSIISS
       od [[-v]] [[-A _a_d_d_r_e_s_s___b_a_s_e]] [[-j _s_k_i_p]] [[-N _c_o_u_n_t]] [[-t _t_y_p_e___s_t_r_i_n_g]]...
           [[_f_i_l_e...]]

       od [[-bcdosx]] [[_f_i_l_e]] [[[[+]]_o_f_f_s_e_t[[.]][[b]]]]

DDEESSCCRRIIPPTTIIOONN
       The _o_d utility shall write the contents of its input files to standard
       output in a user-specified format.

OOPPTTIIOONNSS
       The _o_d utility shall conform to the Base Definitions volume of
       POSIX.1-2017, _S_e_c_t_i_o_n _1_2_._2, _U_t_i_l_i_t_y _S_y_n_t_a_x _G_u_i_d_e_l_i_n_e_s, except that the
       order of presentation of the --tt options and the --bbccddoossxx options is
       significant.

       The following options shall be supported:

       --AA _a_d_d_r_e_s_s___b_a_s_e
                 Specify the input offset base. See the EXTENDED DESCRIPTION
                 section.  The application shall ensure that the _a_d_d_r_e_s_s___b_a_s_e
                 option-argument is a character. The characters ''dd'', ''oo'', and
                 ''xx'' specify that the offset base shall be written in decimal,
                 octal, or hexadecimal, respectively. The character ''nn''
                 specifies that the offset shall not be written.

       --bb        Interpret bytes in octal. This shall be equivalent to --tt oo11.

       --cc        Interpret bytes as characters specified by the current
                 setting of the _L_C___C_T_Y_P_E category. Certain non-graphic
                 characters appear as C escapes: ""NNUULL==\\00"", ""BBSS==\\bb"", ""FFFF==\\ff"",
                 ""NNLL==\\nn"", ""CCRR==\\rr"", ""HHTT==\\tt""; others appear as 3-digit octal
                 numbers.

       --dd        Interpret _w_o_r_ds (two-byte units) in unsigned decimal. This
                 shall be equivalent to --tt uu22.

       --jj _s_k_i_p   Jump over _s_k_i_p bytes from the beginning of the input. The _o_d
                 utility shall read or seek past the first _s_k_i_p bytes in the
                 concatenated input files. If the combined input is not at
                 least _s_k_i_p bytes long, the _o_d utility shall write a
                 diagnostic message to standard error and exit with a non-zero
                 exit status.

                 By default, the _s_k_i_p 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 ''00'', the offset shall be interpreted as an octal
                 number. Appending the character ''bb'', ''kk'', or ''mm'' to offset
                 shall cause it to be interpreted as a multiple of 512, 1024,
                 or 1048576 bytes, respectively. If the _s_k_i_p number is
                 hexadecimal, any appended ''bb'' shall be considered to be the
                 final hexadecimal digit.

       --NN _c_o_u_n_t  Format no more than _c_o_u_n_t bytes of input. By default, _c_o_u_n_t
                 shall be interpreted as a decimal number. With a leading 0x
                 or 0X, _c_o_u_n_t shall be interpreted as a hexadecimal number;
                 otherwise, with a leading ''00'', it shall be interpreted as an
                 octal number. If _c_o_u_n_t bytes of input (after successfully
                 skipping, if --jj _s_k_i_p is specified) are not available, it
                 shall not be considered an error; the _o_d utility shall format
                 the input that is available.

       --oo        Interpret _w_o_r_ds (two-byte units) in octal. This shall be
                 equivalent to --tt oo22.

       --ss        Interpret _w_o_r_ds (two-byte units) in signed decimal. This
                 shall be equivalent to --tt dd22.

       --tt _t_y_p_e___s_t_r_i_n_g
                 Specify one or more output types. See the EXTENDED
                 DESCRIPTION section. The application shall ensure that the
                 _t_y_p_e___s_t_r_i_n_g 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 aa, cc, dd, ff, oo,
                 uu, and xx, specifying named character, character, signed
                 decimal, floating point, octal, unsigned decimal, and
                 hexadecimal, respectively. The type specification characters
                 dd, ff, oo, uu, and xx 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 ff can be followed by an optional FF,
                 DD, or LL indicating that the conversion should be applied to
                 an item of type ffllooaatt, ddoouubbllee, or lloonngg ddoouubbllee, respectively.
                 The type specification characters dd, oo, uu, and xx can be
                 followed by an optional CC, SS, II, or LL indicating that the
                 conversion should be applied to an item of type cchhaarr, sshhoorrtt,
                 iinntt, or lloonngg, respectively. Multiple types can be
                 concatenated within the same _t_y_p_e___s_t_r_i_n_g and multiple --tt
                 options can be specified. Output lines shall be written for
                 each type specified in the order in which the type
                 specification characters are specified.

       --vv        Write all input data. Without the --vv 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> (''**'').

       --xx        Interpret _w_o_r_ds (two-byte units) in hexadecimal. This shall
                 be equivalent to --tt xx22.

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

OOPPEERRAANNDDSS
       The following operands shall be supported:

       _f_i_l_e      A pathname of a file to be read. If no _f_i_l_e operands are
                 specified, the standard input shall be used.

                 If there are no more than two operands, none of the --AA, --jj,
                 --NN, --tt, or --vv options is specified, and either of the
                 following is true: the first character of the last operand is
                 a <plus-sign> (''++''), 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.

       [[++]]_o_f_f_s_e_t[[..]][[bb]]
                 The _o_f_f_s_e_t 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 shall be
                 interpreted in decimal. If ''bb'' is appended, the offset shall
                 be interpreted in units of 512 bytes.

SSTTDDIINN
       The standard input shall be used if no _f_i_l_e operands are specified, and
       shall be used if a _f_i_l_e operand is ''--'' and the implementation treats
       the ''--'' as meaning standard input.  Otherwise, the standard input shall
       not be used.  See the INPUT FILES section.

IINNPPUUTT FFIILLEESS
       The input files can be any file type.

EENNVVIIRROONNMMEENNTT VVAARRIIAABBLLEESS
       The following environment variables shall affect the execution of _o_d:

       _L_A_N_G      Provide a default value for the internationalization
                 variables that are unset or null. (See the Base Definitions
                 volume of POSIX.1-2017, _S_e_c_t_i_o_n _8_._2, _I_n_t_e_r_n_a_t_i_o_n_a_l_i_z_a_t_i_o_n
                 _V_a_r_i_a_b_l_e_s for the precedence of internationalization
                 variables used to determine the values of locale categories.)

       _L_C___A_L_L    If set to a non-empty string value, override the values of
                 all the other internationalization variables.

       _L_C___C_T_Y_P_E  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).

       _L_C___M_E_S_S_A_G_E_S
                 Determine the locale that should be used to affect the format
                 and contents of diagnostic messages written to standard
                 error.

       _L_C___N_U_M_E_R_I_C
                 Determine the locale for selecting the radix character used
                 when writing floating-point formatted output.

       _N_L_S_P_A_T_H   Determine the location of message catalogs for the processing
                 of _L_C___M_E_S_S_A_G_E_S.

AASSYYNNCCHHRROONNOOUUSS EEVVEENNTTSS
       Default.

SSTTDDOOUUTT
       See the EXTENDED DESCRIPTION section.

SSTTDDEERRRR
       The standard error shall be used only for diagnostic messages.

OOUUTTPPUUTT FFIILLEESS
       None.

EEXXTTEENNDDEEDD DDEESSCCRRIIPPTTIIOONN
       The _o_d utility shall copy sequentially each input file to standard
       output, transforming the input data according to the output types
       specified by the --tt option or the --bbccddoossxx options.  If no output type
       is specified, the default output shall be as if --tt ooSS had been
       specified.

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

       The default number of bytes transformed by output type specifiers dd, ff,
       oo, uu, and xx corresponds to the various C-language types as follows. If
       the _c_9_9 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-2008.

        *  For the type specifier characters dd, oo, uu, and xx, 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 cchhaarr, sshhoorrtt, iinntt, and lloonngg.  These
           numbers can also be specified by an application as the characters
           ''CC'', ''SS'', ''II'', and ''LL'', 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 lloonngg lloonngg.  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.

        *  For the type specifier character ff, 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 ffllooaatt,, ddoouubbllee, and lloonngg ddoouubbllee.  These numbers can
           also be specified by an application as the characters ''FF'', ''DD'', and
           ''LL'', respectively.

       The type specifier character aa 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.

                            TTaabbllee:: NNaammeedd CChhaarraacctteerrss iinn _o_d

          +-------------+--------------+-------------------+--------------+
          |VVaalluuee   NNaammee | VVaalluuee   NNaammee | VVaalluuee     NNaammee    | VVaalluuee   NNaammee |
          +-------------+--------------+-------------------+--------------+
          |\000    nnuull  | \001    ssoohh  | \002    ssttxx       | \003    eettxx  |
          |\004    eeoott  | \005    eennqq  | \006    aacckk       | \007    bbeell  |
          |\010    bbss   | \011    hhtt   | \012    llff or nnll** | \013    vvtt   |
          |\014    ffff   | \015    ccrr   | \016    ssoo        | \017    ssii   |
          |\020    ddllee  | \021    ddcc11  | \022    ddcc22       | \023    ddcc33  |
          |\024    ddcc44  | \025    nnaakk  | \026    ssyynn       | \027    eettbb  |
          |\030    ccaann  | \031    eemm   | \032    ssuubb       | \033    eesscc  |
          |\034    ffss   | \035    ggss   | \036    rrss        | \037    uuss   |
          |\040    sspp   | \177    ddeell  |                   |              |
          +-------------+--------------+-------------------+--------------+
       NNoottee::     The ""\\001122"" value may be written either as llff or nnll.

       The type specifier character cc specifies that bytes shall be
       interpreted as characters specified by the current setting of the
       _L_C___C_T_Y_P_E locale category. Characters listed in the table in the Base
       Definitions volume of POSIX.1-2017, _C_h_a_p_t_e_r _5, _F_i_l_e _F_o_r_m_a_t _N_o_t_a_t_i_o_n
       (''\\\\'', ''\\aa'', ''\\bb'', ''\\ff'', ''\\nn'', ''\\rr'', ''\\tt'', ''\\vv'') 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 ''\\00''.
       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 ""****"" 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 --jj _s_k_i_p or
       --NN _c_o_u_n_t option is specified along with the cc 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.

       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.

       If, as a result of the specification of the --NN 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.

       Unless --AA nn 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.

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

EEXXIITT SSTTAATTUUSS
       The following exit values shall be returned:

        0    All input files were processed successfully.

       >0    An error occurred.

CCOONNSSEEQQUUEENNCCEESS OOFF EERRRROORRSS
       Default.

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       XSI-conformant 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 --AA, --jj, or --NN 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 --AA option.

EEXXAAMMPPLLEESS
       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 volume of POSIX.1-2017 allows nnll or llff to be used as the
       name for the ISO/IEC 646:1991 standard IRV character with decimal value
       10. The IRV names this character llff (line feed), but traditional
       implementations have referred to this character as newline (nnll) and the
       POSIX locale character set symbolic name for the corresponding
       character is a <newline>.

       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, IEEE Std 754-1985 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

RRAATTIIOONNAALLEE
       The _o_d utility went through several names in early proposals, including
       _h_d, _x_d, and most recently _h_e_x_d_u_m_p.  There were several objections to
       all of these based on the following reasons:

        *  The _h_d and _x_d names conflicted with historical utilities that
           behaved differently.

        *  The _h_e_x_d_u_m_p description was much more complex than needed for a
           simple dump utility.

        *  The _o_d 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 _o_d utility.

       The original reasons for not standardizing historical _o_d 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:

        *  The BSD and System V versions of _o_d 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 sshhoorrtts, signed and unsigned
           decimal sshhoorrtts, hexadecimal sshhoorrtts, and ASCII characters. BSD added
           the ability to dump ffllooaatts, ddoouubbllees, named ASCII characters, and
           octal, signed decimal, unsigned decimal, and hexadecimal lloonnggs.
           The version presented here provides more normalized forms for
           dumping bytes, sshhoorrtts, iinntts, and lloonnggs in octal, signed decimal,
           unsigned decimal, and hexadecimal; ffllooaatt, ddoouubbllee, and lloonngg ddoouubbllee;
           and named ASCII as well as current locale characters.

        *  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 _o_d output is the
           specified default output of this utility. None of the option
           letters chosen for this version of _o_d conflict with any of the
           options to historical versions of _o_d.

        *  On systems with different sizes for sshhoorrtt, iinntt, and lloonngg, there was
           no way to ask for dumps of iinntts, 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 --tt option was added (with
           type specifiers more closely matched to the _p_r_i_n_t_f() formats used
           in the rest of this volume of POSIX.1-2017) and the optional field
           sizes were added to the dd, ff, oo, uu, and xx type specifiers. It is
           also one of the reasons why the historical practice was not
           mandated as a required obsolescent form of _o_d.  (Although the old
           versions of _o_d are not listed as an obsolescent form,
           implementations are urged to continue to recognize the older forms
           for several more years.) The aa, cc, ff, oo, and xx types match the
           meaning of the corresponding format characters in the historical
           implementations of _o_d except for the default sizes of the fields
           converted. The dd format is signed in this volume of POSIX.1-2017 to
           match the _p_r_i_n_t_f() notation. (Historical versions of _o_d used dd as a
           synonym for uu in this version. The System V implementation uses ss
           for signed decimal; BSD uses ii for signed decimal and ss for null-
           terminated strings.) Other than dd and uu, all of the type specifiers
           match format characters in the historical BSD version of oodd.

           The sizes of the C-language types cchhaarr, sshhoorrtt, iinntt, lloonngg, ffllooaatt,
           ddoouubbllee, and lloonngg ddoouubbllee 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 sshhoorrtts, 2
           bytes iinntts, and 4 bytes lloonnggs, while another compiler (or an option
           to the same compiler) uses 2 bytes sshhoorrtts, 4 bytes iinntts, and 4
           bytes lloonnggs.)  Nonetheless, there has to be a basic size known by
           the implementation for these types, corresponding to the values
           reported by invocations of the _g_e_t_c_o_n_f utility when called with
           _s_y_s_t_e_m___v_a_r operands {UCHAR_MAX}, {USHORT_MAX}, {UINT_MAX}, and
           {ULONG_MAX} for the types cchhaarr, sshhoorrtt, iinntt, and lloonngg, respectively.
           There are similar constants required by the ISO C standard, but not
           required by the System Interfaces volume of POSIX.1-2017 or this
           volume of POSIX.1-2017. They are {FLT_MANT_DIG}, {DBL_MANT_DIG},
           and {LDBL_MANT_DIG} for the types ffllooaatt, ddoouubbllee, and lloonngg ddoouubbllee,
           respectively. If the optional _c_9_9 utility is provided by the
           implementation and used as specified by this volume of
           POSIX.1-2017, 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 _o_d utility is able to interpret
           binary data output by such a program correctly.

           This volume of POSIX.1-2017 requires that the numeric values of
           these lengths be recognized by the _o_d utility and that symbolic
           forms also be recognized. Thus, a conforming application can always
           look at an array of uunnssiiggnneedd lloonngg data elements using _o_d --tt _u_L.

        *  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 --AA option now specifies the address base and the --SS
           option specifies a starting offset.

        *  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 _o_d to dump characters in the current locale than it is
           for the _e_d or _s_e_d ll commands. The cc type specifier does this
           without difficulty and is completely compatible with the historical
           implementations of the cc format character when the current locale
           uses a superset of the ISO/IEC 646:1991 standard as a codeset. The
           aa type specifier (from the BSD aa 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 _p_a_x could be deciphered
           even on systems that do not use the ISO/IEC 646:1991 standard as a
           subset of their base codeset.

       The use of ""****"" as an indication of continuation of a multi-byte
       character in cc 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.

       An early proposal used --SS and --nn, respectively, for the --jj and --NN
       options eventually selected. These were changed to avoid conflicts with
       historical implementations.

       The original standard specified --tt oo22 as the default when no output
       type was given. This was changed to --tt ooSS (the length of a sshhoorrtt) 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.

       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.

       Earlier versions of this standard allowed for implementations with
       bytes other than eight bits, but this has been modified in this
       version.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       All option and operand interfaces marked XSI may be removed in a future
       version.

SSEEEE AALLSSOO
       _c_9_9, _s_e_d

       The Base Definitions volume of POSIX.1-2017, _C_h_a_p_t_e_r _5, _F_i_l_e _F_o_r_m_a_t
       _N_o_t_a_t_i_o_n, _C_h_a_p_t_e_r _8, _E_n_v_i_r_o_n_m_e_n_t _V_a_r_i_a_b_l_e_s, _S_e_c_t_i_o_n _1_2_._2, _U_t_i_l_i_t_y
       _S_y_n_t_a_x _G_u_i_d_e_l_i_n_e_s

CCOOPPYYRRIIGGHHTT
       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 .

       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 .



IEEE/The Open Group                  2017                                OD(1)
