1OD(1P)                     POSIX Programmer's Manual                    OD(1P)
2
3
4

PROLOG

6       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
7       implementation of this interface may differ (consult the  corresponding
8       Linux  manual page for details of Linux behavior), or the interface may
9       not be implemented on Linux.
10
11

NAME

13       od — dump files in various formats
14

SYNOPSIS

16       od [−v] [−A address_base] [−j skip] [−N count] [−t type_string]...
17           [file...]
18
19       od [−bcdosx] [file] [[+]offset[.][b]]
20

DESCRIPTION

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

OPTIONS

26       The  od  utility  shall  conform  to  the  Base  Definitions  volume of
27       POSIX.1‐2008, Section 12.2, Utility Syntax Guidelines, except that  the
28       order of presentation of the −t options and the −bcdosx options is sig‐
29       nificant.
30
31       The following options shall be supported:
32
33       −A address_base
34                 Specify the input offset base. See the  EXTENDED  DESCRIPTION
35                 section.   The application shall ensure that the address_base
36                 option-argument is a character. The characters 'd', 'o',  and
37                 'x' specify that the offset base shall be written in decimal,
38                 octal, or hexadecimal, respectively. The character 'n' speci‐
39                 fies that the offset shall not be written.
40
41       −b        Interpret bytes in octal. This shall be equivalent to −t o1.
42
43       −c        Interpret  bytes  as characters specified by the current set‐
44                 ting of the LC_CTYPE category. Certain non-graphic characters
45                 appear  as  C  escapes:  "NUL=\0", "BS=\b", "FF=\f", "NL=\n",
46                 "CR=\r", "HT=\t"; others appear as 3-digit octal numbers.
47
48       −d        Interpret words (two-byte units) in  unsigned  decimal.  This
49                 shall be equivalent to −t u2.
50
51       −j skip   Jump  over skip bytes from the beginning of the input. The od
52                 utility shall read or seek past the first skip bytes  in  the
53                 concatenated  input  files.  If  the combined input is not at
54                 least skip bytes long, the od utility shall write a  diagnos‐
55                 tic  message  to standard error and exit with a non-zero exit
56                 status.
57
58                 By default, the skip option-argument shall be interpreted  as
59                 a  decimal  number. With a leading 0x or 0X, the offset shall
60                 be interpreted as a hexadecimal  number;  otherwise,  with  a
61                 leading '0', the offset shall be interpreted as an octal num‐
62                 ber. Appending the character 'b', 'k', or 'm' to offset shall
63                 cause  it  to  be  interpreted as a multiple of 512, 1024, or
64                 1048576 bytes, respectively. If the skip number is  hexadeci‐
65                 mal,  any  appended  'b'  shall be considered to be the final
66                 hexadecimal digit.
67
68       −N count  Format no more than count bytes of input. By  default,  count
69                 shall  be  interpreted as a decimal number. With a leading 0x
70                 or 0X, count shall be interpreted as  a  hexadecimal  number;
71                 otherwise,  with a leading '0', it shall be interpreted as an
72                 octal number. If count bytes  of  input  (after  successfully
73                 skipping,  if  −j  skip  is  specified) are not available, it
74                 shall not be considered an error; the od utility shall format
75                 the input that is available.
76
77       −o        Interpret  words  (two-byte  units)  in  octal. This shall be
78                 equivalent to −t o2.
79
80       −s        Interpret words (two-byte  units)  in  signed  decimal.  This
81                 shall be equivalent to −t d2.
82
83       −t type_string
84                 Specify  one  or more output types. See the EXTENDED DESCRIP‐
85                 TION  section.  The  application  shall   ensure   that   the
86                 type_string  option-argument is a string specifying the types
87                 to be used when writing the input data. The string shall con‐
88                 sist  of  the type specification characters a, c, d, f, o, u,
89                 and x, specifying named character, character, signed decimal,
90                 floating  point,  octal,  unsigned  decimal, and hexadecimal,
91                 respectively. The type specification characters d, f,  o,  u,
92                 and x can be followed by an optional unsigned decimal integer
93                 that specifies the number of bytes to be transformed by  each
94                 instance of the output type. The type specification character
95                 f can be followed by an optional F, D, or L  indicating  that
96                 the  conversion  should  be applied to an item of type float,
97                 double, or long double, respectively. The type  specification
98                 characters  d,  o, u, and x can be followed by an optional C,
99                 S, I, or L indicating that the conversion should  be  applied
100                 to  an  item of type char, short, int, or long, respectively.
101                 Multiple  types  can  be   concatenated   within   the   same
102                 type_string  and multiple −t options can be specified. Output
103                 lines shall be written for each type specified in  the  order
104                 in which the type specification characters are specified.
105
106       −v        Write  all  input  data. Without the −v option, any number of
107                 groups of output lines, which would be identical to the imme‐
108                 diately  preceding group of output lines (except for the byte
109                 offsets), shall be replaced with a line  containing  only  an
110                 <asterisk> ('*').
111
112       −x        Interpret  words  (two-byte units) in hexadecimal. This shall
113                 be equivalent to −t x2.
114
115       Multiple types can be specified by  using  multiple  −bcdostx  options.
116       Output  lines are written for each type specified in the order in which
117       the types are specified.
118

OPERANDS

120       The following operands shall be supported:
121
122       file      A pathname of a file to be read.  If  no  file  operands  are
123                 specified, the standard input shall be used.
124
125                 If  there  are no more than two operands, none of the −A, −j,
126                 −N, −t, or −v options is specified, and either of the follow‐
127                 ing  is  true:  the  first character of the last operand is a
128                 <plus-sign> ('+'), or there are two operands  and  the  first
129                 character  of  the  last operand is numeric; the last operand
130                 shall be interpreted as an offset operand  on  XSI-conformant
131                 systems.  Under these conditions, the results are unspecified
132                 on systems that are not XSI-conformant systems.
133
134       [+]offset[.][b]
135                 The offset operand specifies the offset  in  the  file  where
136                 dumping is to commence.  This operand is normally interpreted
137                 as octal bytes. If '.'  is  appended,  the  offset  shall  be
138                 interpreted  in decimal. If 'b' is appended, the offset shall
139                 be interpreted in units of 512 bytes.
140

STDIN

142       The standard input shall be used if no file operands are specified, and
143       shall  be  used  if a file operand is '−' and the implementation treats
144       the '−' as meaning standard input.  Otherwise, the standard input shall
145       not be used.  See the INPUT FILES section.
146

INPUT FILES

148       The input files can be any file type.
149

ENVIRONMENT VARIABLES

151       The following environment variables shall affect the execution of od:
152
153       LANG      Provide  a  default  value for the internationalization vari‐
154                 ables that are unset or null. (See the Base Definitions  vol‐
155                 ume  of POSIX.1‐2008, Section 8.2, Internationalization Vari‐
156                 ables for the precedence  of  internationalization  variables
157                 used to determine the values of locale categories.)
158
159       LC_ALL    If  set  to  a non-empty string value, override the values of
160                 all the other internationalization variables.
161
162       LC_CTYPE  Determine the locale for the interpretation of  sequences  of
163                 bytes of text data as characters (for example, single-byte as
164                 opposed to  multi-byte  characters  in  arguments  and  input
165                 files).
166
167       LC_MESSAGES
168                 Determine the locale that should be used to affect the format
169                 and contents  of  diagnostic  messages  written  to  standard
170                 error.
171
172       LC_NUMERIC
173                 Determine  the  locale for selecting the radix character used
174                 when writing floating-point formatted output.
175
176       NLSPATH   Determine the location of message catalogs for the processing
177                 of LC_MESSAGES.
178

ASYNCHRONOUS EVENTS

180       Default.
181

STDOUT

183       See the EXTENDED DESCRIPTION section.
184

STDERR

186       The standard error shall be used only for diagnostic messages.
187

OUTPUT FILES

189       None.
190

EXTENDED DESCRIPTION

192       The od utility shall copy sequentially each input file to standard out‐
193       put, transforming the input data according to the output  types  speci‐
194       fied  by  the  −t  option or the −bcdosx options.  If no output type is
195       specified, the default output shall be as if −t oS had been specified.
196
197       The number of bytes transformed by the output type specifier c  may  be
198       variable depending on the LC_CTYPE category.
199
200       The default number of bytes transformed by output type specifiers d, f,
201       o, u, and x corresponds to the various C-language types as follows.  If
202       the  c99 compiler is present on the system, these specifiers shall cor‐
203       respond to the sizes used by default in that compiler. Otherwise, these
204       sizes may vary among systems that conform to POSIX.1‐2008.
205
206        *  For  the type specifier characters d, o, u, and x, the default num‐
207           ber of bytes shall correspond to the size of the underlying  imple‐
208           mentation's basic integer type. For these specifier characters, the
209           implementation shall support values of the optional number of bytes
210           to  be converted corresponding to the number of bytes in the C-lan‐
211           guage types char, short, int, and long.  These numbers can also  be
212           specified  by  an  application as the characters 'C', 'S', 'I', and
213           'L', respectively. The implementation shall also support the values
214           1,  2,  4,  and 8, even if it provides no C-Language types of those
215           sizes. The implementation shall support the  decimal  value  corre‐
216           sponding  to  the  C-language  type long long.  The byte order used
217           when interpreting numeric  values  is  implementation-defined,  but
218           shall  correspond  to  the  order in which a constant of the corre‐
219           sponding type is stored in memory on the system.
220
221        *  For the type specifier character f, the  default  number  of  bytes
222           shall correspond to the number of bytes in the underlying implemen‐
223           tation's basic  double  precision  floating-point  data  type.  The
224           implementation shall support values of the optional number of bytes
225           to be converted corresponding to the number of bytes in the  C-lan‐
226           guage types float, double, and long double.  These numbers can also
227           be specified by an application as the characters 'F', 'D', and 'L',
228           respectively.
229
230       The  type  specifier  character  a specifies that bytes shall be inter‐
231       preted as named characters from  the  International  Reference  Version
232       (IRV)  of  the  ISO/IEC 646:1991  standard.  Only the least significant
233       seven bits of each byte shall be  used  for  this  type  specification.
234       Bytes  with  the  values listed in the following table shall be written
235       using the corresponding names for those characters.
236
237                            Table: Named Characters in od
238
239          ┌─────────────┬──────────────┬───────────────────┬──────────────┐
240Value   Name Value   Name Value     Name    Value   Name 
241          ├─────────────┼──────────────┼───────────────────┼──────────────┤
242          │\000    nul  │ \001    soh  │ \002    stx       │ \003    etx  
243          │\004    eot  │ \005    enq  │ \006    ack       │ \007    bel  
244          │\010    bs   │ \011    ht   │ \012    lf or nl* │ \013    vt   
245          │\014    ff   │ \015    cr   │ \016    so        │ \017    si   
246          │\020    dle  │ \021    dc1  │ \022    dc2       │ \023    dc3  
247          │\024    dc4  │ \025    nak  │ \026    syn       │ \027    etb  
248          │\030    can  │ \031    em   │ \032    sub       │ \033    esc  
249          │\034    fs   │ \035    gs   │ \036    rs        │ \037    us   
250          │\040    sp   │ \177    del  │                   │              │
251          └─────────────┴──────────────┴───────────────────┴──────────────┘
252       Note:     The "\012" value may be written either as lf or nl.
253
254       The type specifier character c specifies that  bytes  shall  be  inter‐
255       preted  as  characters specified by the current setting of the LC_CTYPE
256       locale category. Characters listed in the table in the Base Definitions
257       volume  of  POSIX.1‐2008,  Chapter 5, File Format Notation ('\\', '\a',
258       '\b', '\f', '\n', '\r', '\t', '\v') shall be written as the correspond‐
259       ing  escape  sequences,  except  that <backslash> shall be written as a
260       single <backslash> and a NUL shall be  written  as  '\0'.   Other  non-
261       printable  characters  shall be written as one three-digit octal number
262       for each byte in the character. Printable multi-byte  characters  shall
263       be  written  in the area corresponding to the first byte of the charac‐
264       ter; the two-character sequence "**" shall be written in the area  cor‐
265       responding  to  each  remaining byte in the character, as an indication
266       that the character is continued. When either the −j skip  or  −N  count
267       option  is  specified along with the c type specifier, and this results
268       in an attempt to start or finish in the middle of a multi-byte  charac‐
269       ter, the result is implementation-defined.
270
271       The input data shall be manipulated in blocks, where a block is defined
272       as a multiple of the least common  multiple  of  the  number  of  bytes
273       transformed by the specified output types. If the least common multiple
274       is greater than 16, the results are unspecified. Each input block shall
275       be written as transformed by each output type, one per written line, in
276       the order that the output types were specified. If the input block size
277       is  larger than the number of bytes transformed by the output type, the
278       output type shall sequentially transform the parts of the input  block,
279       and  the  output from each of the transformations shall be separated by
280       one or more <blank> characters.
281
282       If, as a result of the specification of the −N  option  or  end-of-file
283       being  reached on the last input file, input data only partially satis‐
284       fies an output type, the input shall be extended sufficiently with null
285       bytes to write the last byte of the input.
286
287       Unless −A n is specified, the first output line produced for each input
288       block shall be preceded by the input offset,  cumulative  across  input
289       files,  of  the next byte to be written. The format of the input offset
290       is unspecified; however, it shall not contain any  <blank>  characters,
291       shall  start  at  the  first character of the output line, and shall be
292       followed by one or more <blank> characters. In addition, the offset  of
293       the byte following the last byte written shall be written after all the
294       input data has been processed, but shall not be followed by any <blank>
295       characters.
296
297       If no −A option is specified, the input offset base is unspecified.
298

EXIT STATUS

300       The following exit values shall be returned:
301
302        0    All input files were processed successfully.
303
304       >0    An error occurred.
305

CONSEQUENCES OF ERRORS

307       Default.
308
309       The following sections are informative.
310

APPLICATION USAGE

312       XSI-conformant  applications  are  warned not to use filenames starting
313       with '+' or a first operand starting with a numeric character  so  that
314       the old functionality can be maintained by implementations, unless they
315       specify one of the −A, −j, or −N options.  To  guarantee  that  one  of
316       these  filenames  is  always  interpreted as a filename, an application
317       could always specify the address base format with the −A option.
318

EXAMPLES

320       If a file containing 128 bytes with decimal  values  zero  to  127,  in
321       increasing order, is supplied as standard input to the command:
322
323           od −A d −t a
324
325       on  an  implementation using an input block size of 16 bytes, the stan‐
326       dard output, independent of the current locale setting, would be  simi‐
327       lar to:
328
329           0000000 nul soh stx etx eot enq ack bel  bs  ht  nl  vt  ff  cr  so  si
330           0000016 dle dc1 dc2 dc3 dc4 nak syn etb can  em sub esc  fs  gs  rs  us
331           0000032  sp   !   "   #   $   %   &   '   (   )   *   +   ,   −   .  /
332           0000048   0   1   2   3   4   5   6   7   8   9   :   ;   <   =   >   ?
333           0000064   @   A   B   C   D   E   F   G   H   I   J   K   L   M   N   O
334           0000080   P   Q   R   S   T   U   V   W   X   Y   Z   [   \   ]   ^   _
335           0000096   `   a   b   c   d   e   f   g   h   i   j   k   l   m   n   o
336           0000112   p   q   r   s   t   u   v   w   x   y   z   {   |   }   ~ del
337           0000128
338
339       Note that this volume of POSIX.1‐2008 allows nl or lf to be used as the
340       name for the ISO/IEC 646:1991 standard IRV character with decimal value
341       10. The IRV names this character lf (line feed), but traditional imple‐
342       mentations have referred to this character  as  newline  (nl)  and  the
343       POSIX  locale character set symbolic name for the corresponding charac‐
344       ter is a <newline>.
345
346       The command:
347
348           od −A o −t o2x2x −N 18
349
350       on a system with 32-bit words and  an  implementation  using  an  input
351       block  size  of 16 bytes could write 18 bytes in approximately the fol‐
352       lowing format:
353
354           0000000 032056 031440 041123 042040 052516 044530 020043 031464
355                     342e   3320   4253   4420   554e   4958   2023   3334
356                        342e3320      42534420      554e4958      20233334
357           0000020 032472
358                     353a
359                        353a0000
360           0000022
361
362       The command:
363
364           od −A d −t f −t o4 −t x4 −N 24 −j 0x15
365
366       on a system with 64-bit doubles (for example, IEEE Std 754‐1985  double
367       precision  floating-point format) would skip 21 bytes of input data and
368       then write 24 bytes in approximately the following format:
369
370           0000000    1.00000000000000e+00    1.57350000000000e+01
371                   07774000000 00000000000 10013674121 35341217270
372                      3ff00000    00000000    402f3851    eb851eb8
373           0000016    1.40668230000000e+02
374                   10030312542 04370303230
375                      40619562    23e18698
376           0000024
377

RATIONALE

379       The od utility went through several names in early proposals, including
380       hd,  xd,  and  most recently hexdump.  There were several objections to
381       all of these based on the following reasons:
382
383        *  The hd and xd  names  conflicted  with  historical  utilities  that
384           behaved differently.
385
386        *  The  hexdump  description  was  much more complex than needed for a
387           simple dump utility.
388
389        *  The od utility has been available on all historical implementations
390           and there was no need to create a new name for a utility so similar
391           to the historical od utility.
392
393       The original reasons for not  standardizing  historical  od  were  also
394       fairly  widespread.  Those reasons are given below along with rationale
395       explaining why the standard developers believe that this  version  does
396       not suffer from the indicated problem:
397
398        *  The  BSD  and System V versions of od have diverged, and the inter‐
399           section of features provided by both does not meet the needs of the
400           user community. In fact, the System V version only provides a mech‐
401           anism for dumping octal bytes and shorts, signed and unsigned deci‐
402           mal shorts, hexadecimal shorts, and ASCII characters. BSD added the
403           ability to dump floats, doubles, named ASCII characters, and octal,
404           signed  decimal, unsigned decimal, and hexadecimal longs.  The ver‐
405           sion presented here provides  more  normalized  forms  for  dumping
406           bytes,  shorts,  ints, and longs in octal, signed decimal, unsigned
407           decimal, and hexadecimal; float, double, and long double; and named
408           ASCII as well as current locale characters.
409
410        *  It  would  not be possible to come up with a compatible superset of
411           the BSD and System V flags that met the requirements of  the  stan‐
412           dard  developers. The historical default od output is the specified
413           default output of this utility. None of the option  letters  chosen
414           for this version of od conflict with any of the options to histori‐
415           cal versions of od.
416
417        *  On systems with different sizes for short, int, and long, there was
418           no  way  to ask for dumps of ints, even in the BSD version. Because
419           of the way options are named, the name space could not be  extended
420           to  solve these problems. This is why the −t option was added (with
421           type specifiers more closely matched to the printf()  formats  used
422           in  the rest of this volume of POSIX.1‐2008) and the optional field
423           sizes were added to the d, f, o, u, and x type  specifiers.  It  is
424           also  one  of  the reasons why the historical practice was not man‐
425           dated as a required obsolescent form of od.  (Although the old ver‐
426           sions  of od are not listed as an obsolescent form, implementations
427           are urged to continue to recognize the older forms for several more
428           years.) The a, c, f, o, and x types match the meaning of the corre‐
429           sponding format characters in the historical implementations of  od
430           except  for the default sizes of the fields converted. The d format
431           is signed in this volume of  POSIX.1‐2008  to  match  the  printf()
432           notation.  (Historical  versions of od used d as a synonym for u in
433           this version. The System V implementation uses s for  signed  deci‐
434           mal;  BSD  uses  i  for  signed  decimal  and s for null-terminated
435           strings.) Other than d and u, all of the type specifiers match for‐
436           mat characters in the historical BSD version of od.
437
438           The  sizes  of  the C-language types char, short, int, long, float,
439           double, and long double are used even though it is recognized  that
440           there  may  be zero or more than one compiler for the C language on
441           an implementation and that they may use different sizes for some of
442           these types. (For example, one compiler might use 2 bytes shorts, 2
443           bytes ints, and 4 bytes longs, while another compiler (or an option
444           to  the  same  compiler)  uses  2 bytes shorts, 4 bytes ints, and 4
445           bytes longs.)  Nonetheless, there has to be a basic size  known  by
446           the  implementation  for  these  types, corresponding to the values
447           reported by invocations of the getconf  utility  when  called  with
448           system_var  operands  {UCHAR_MAX},  {USHORT_MAX},  {UINT_MAX},  and
449           {ULONG_MAX} for the types char, short, int, and long, respectively.
450           There are similar constants required by the ISO C standard, but not
451           required by the System Interfaces volume of  POSIX.1‐2008  or  this
452           volume  of  POSIX.1‐2008.  They are {FLT_MANT_DIG}, {DBL_MANT_DIG},
453           and {LDBL_MANT_DIG} for the types float, double, and  long  double,
454           respectively. If the optional c99 utility is provided by the imple‐
455           mentation and used as specified by  this  volume  of  POSIX.1‐2008,
456           these  are  the  sizes that would be provided. If an option is used
457           that specifies different sizes for these types, there is no guaran‐
458           tee  that the od utility is able to interpret binary data output by
459           such a program correctly.
460
461           This volume of POSIX.1‐2008 requires that  the  numeric  values  of
462           these  lengths  be  recognized  by the od utility and that symbolic
463           forms also be recognized. Thus, a conforming application can always
464           look at an array of unsigned long data elements using od −t uL.
465
466        *  The  method of specifying the format for the address field based on
467           specifying a starting offset in a file unnecessarily tied  the  two
468           together.  The  −A option now specifies the address base and the −S
469           option specifies a starting offset.
470
471        *  It would be difficult to  break  the  dependence  on  US  ASCII  to
472           achieve  an  internationalized  utility. It does not seem to be any
473           harder for od to dump characters in the current locale than  it  is
474           for  the ed or sed l commands. The c type specifier does this with‐
475           out difficulty and is completely  compatible  with  the  historical
476           implementations  of  the c format character when the current locale
477           uses a superset of the ISO/IEC 646:1991 standard as a codeset.  The
478           a  type  specifier  (from the BSD a format character) was left as a
479           portable means to dump ASCII (or  more  correctly  ISO/IEC 646:1991
480           standard (IRV)) so that headers produced by pax could be deciphered
481           even on systems that do not use the ISO/IEC 646:1991 standard as  a
482           subset of their base codeset.
483
484       The  use of "**" as an indication of continuation of a multi-byte char‐
485       acter in c specifier output was chosen based on seeing  an  implementa‐
486       tion that uses this method. The continuation bytes have to be marked in
487       a way that is not ambiguous  with  another  single-byte  or  multi-byte
488       character.
489
490       An  early  proposal  used  −S  and  −n, respectively, for the −j and −N
491       options eventually selected. These were changed to avoid conflicts with
492       historical implementations.
493
494       The  original  standard  specified  −t o2 as the default when no output
495       type was given. This was changed to −t oS (the length of  a  short)  to
496       accommodate  a  supercomputer  implementation that historically used 64
497       bits as its default (and that defined shorts as 64 bits).  This  change
498       should  not  affect conforming applications. The requirement to support
499       lengths of 1, 2, and 4 was added at the same time to address an histor‐
500       ical implementation that had no two-byte data types in its C compiler.
501
502       The use of a basic integer data type is intended to allow the implemen‐
503       tation to choose a word size commonly  used  by  applications  on  that
504       architecture.
505
506       Earlier  versions  of  this  standard  allowed for implementations with
507       bytes other than eight bits, but this has been modified  in  this  ver‐
508       sion.
509

FUTURE DIRECTIONS

511       All option and operand interfaces marked XSI may be removed in a future
512       version.
513

SEE ALSO

515       c99, sed
516
517       The Base Definitions volume of POSIX.1‐2008,  Chapter  5,  File  Format
518       Notation,  Chapter 8, Environment Variables, Section 12.2, Utility Syn‐
519       tax Guidelines
520
522       Portions of this text are reprinted and reproduced in  electronic  form
523       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
524       -- Portable Operating System Interface (POSIX),  The  Open  Group  Base
525       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
526       cal and Electronics Engineers,  Inc  and  The  Open  Group.   (This  is
527       POSIX.1-2008  with  the  2013  Technical Corrigendum 1 applied.) In the
528       event of any discrepancy between this version and the original IEEE and
529       The  Open Group Standard, the original IEEE and The Open Group Standard
530       is the referee document. The original Standard can be  obtained  online
531       at http://www.unix.org/online.html .
532
533       Any  typographical  or  formatting  errors that appear in this page are
534       most likely to have been introduced during the conversion of the source
535       files  to  man page format. To report such errors, see https://www.ker
536       nel.org/doc/man-pages/reporting_bugs.html .
537
538
539
540IEEE/The Open Group                  2013                               OD(1P)
Impressum