Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretations for IEEE Std 1003.2™-1992 IEEE Standard for Information Technology--Portable Operating System Interfaces (POSIX®)--Part 2: Shell and Utilities

Copyright © 1996 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department, Copyrights and Permissions, 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

Interpretation Request #95
Topic: od file operand Relevant Clauses: 4.45.4

In subclause 4.45.4 of the description of the od utilityØs file operand (P371, L7342-7346), it says: "file A pathname of a file to be read. If no file operands are specified, the standard input shall be used. The results are unspecified it the first character of file is a plus sign (+) or the first character of the first file operand is numeric, unless at least one of the -A, -j, -N, or -t options is specified." Although the rationale doesnØt say this, it seems obvious that the intent of the last sentence in this description was to allow implementations to provide an obsolescent synopsis form, corresponding to historic practice, along the lines of: od [-bcCDdFfOoSsvXx] [filename] [[+]offset[.][b]]

Unfortunately, one common command form: od -c file 10. is not allowed because the offset operand is identified by a numeric as the first character of the "second" file operand. Although the wording in the standard would allow the command: od -c 10. to treat 10 as a decimal offset (rather than as a filename), historic practice (in both System V and BSD implementations) required this to be specified as: od -c +10. To allow implementations to actually provide the historic forms as extensions, the phrase "first character of the first file operand" on P371, L7344-7345 should have been "first character of the second file operand". Was this wording intended to prevent implementations from supporting historic behavior, or was this an editorial mistake?

Interpretation Response
The standard states the behavior for the file operand of the od cmd and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale for Interpretation