Interpretations

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.1™-2001 IEEE Standard for Information Technology - Portable Operating System Interface (POSIX®)

Copyright © 2006 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 #27
Topic: utility extensions violating syntax guidelines Relevant Sections: XBD 12.2 Utility Syntax Guidelines

Is an implementation of a standard utility permitted to support extensions beyond the standard in violation of the Utility Syntax Guidelines when the description of the utility says it shall support them? An example would be an implementation of the head utility supporting the previously obsolescent synopsis , head -42 file rather than head -n 42 file.

Confirmation is sought that an implementation is permitted to have extensions so long as the standard form is also accepted and that the extension is for backwards-compatibility. The proposed rationale is as follows: The last paragraph of 1003.2-1992 2.10.2 and XBD 1003.1-2001 12.2 allows utilities to accept as extensions other forms that do not match the guidelines so long as the standard form is also accepted. Looking at head I would interpret the situation as follow:

1. head -n 42 filename An implementation of the head utility that only accepts this form would be a strictly conforming implementation. This form must be used by conforming applications.
2. head -42 filename An implementation of the head utility that accepts this form ( and the form in 1 above) is a conforming implementation with extensions.

The extension violates the guidelines as allowed by 12.2, but is clearly for backwards compatibility since its a form that was in previous version of the standard. The intent of removing the obsolescent forms of the synopses was not to disallow them to be supported by implementations but to downgrade their status of their use in applications from conforming application using an obsolescent feature to non-conforming application. This form must not be used by conforming application.

Interpretation Response
The standard clearly states the requirements for following the utility syntax guidelines, and conforming implementations must conform to this. Concerns have been raised about former obsolescent forms not being allowed by the standard even as extensions and these are being forwarded to the sponsor. The standard permits implementations to have extensions that violate the Utility Syntax Guidelines so long as when the utility is used in line with the forms defined by the standard that it follows the Utility Syntax Guidelines. Thus head -42 file and ls --help are permitted as extensions.

Rationale for Interpretation
The intent is to allow extensions so long as the standard form is accepted and follows the guidelines.

Notes to the Editor (not part of this interpretation)
A future revision should consider adding the following text to the rationale (before XRAT page 76 line 3076): The standard permits implementations to have extensions that violate the Utility Syntax Guidelines so long as when the utility is used in line with the forms defined by the standard that it follows the Utility Syntax Guidelines. Thus "head -42 file" and "ls --help" are permitted as extensions. The intent is to allow extensions so long as the standard form is accepted and follows the guidelines. Modifications to XCU utility man pages follow to explicitly allow implementations to support previous obsolescent behavior: * set (special built-in) Add a new paragraph p88 before l3417 (before last para in DESCRIPTION) If the first argument is '-', the results are unspecified. * ed p336 Add a new 2nd para to DESCRIPTION If an operand is '-', the results are unspecified. and in the OPERANDS section under "file", remove the last sentence (If the file.... are unspecified). Append to end of first paragraph of OPTIONS (line 12939) "except for the unspecified usage of '-'." * env Add a new paragraph at the end of DESCRIPTION If the first argument is '-', the results are unspecified. Append to end of first paragraph of OPTIONS (line 13581) "except for the unspecified usage of '-'." * head Add to the 2nd paragraph of the RATIONALE for head: Earlier versions of this standard allowed a -number option. This form is no longer specified by this standard but may be present in some implementations. * join page 525 Add new paragraph to the end of RATIONALE Earlier versions of this standard allowed -j, -j1, -j2 options and a form of the -o option that allowed the list option-argument to be multiple arguments. These forms are no longer specified by this standard but may be present in some implementations. * sort Change the first paragraph in OPTIONS from The sort utility shall conform to the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines, and..." to The sort utility shall conform to the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines, except for guideline 9, and..." Add new sentence in the OPTIONS section to the end of the 1st para In addition '+' may be recognized as an option delimiter as well as '-'. Add to RATIONALE (two new paras at the end) Earlier versions of this standard allowed the "-o" option to appear after operands. Historical practice allowed all options to be interspersed with operands. This version of the standard allows implementations to accept options after operands but conforming applications should not use this form. Earlier versions of this standard also allowed the -<i>number</i> and +<i>number</i> options. These options are no longer specified by this standard but may be present in some implementations. * tail Add to the 2nd paragraph of the RATIONALE for tail: Earlier versions of this standard allowed the following forms in the SYNOPSIS section: tail -[number][b|c|l][f] [file] tail +[number][b|c|l][f] [file] These forms are no longer specified by this standard but may be present in some implementations. Append to end of first paragraph of OPTIONS (line 34849) except that '+' may be recognized as an option delimiter as well as '-'. * touch See XCUbug2.txt ERN 45 (which adds text to RATIONALE for touch) * uniq Add in the OPTIONS section to the end of the 1st para at the end of 37135 except that '+' may be recognized as an option delimiter as well as '-'. Add new para to RATIONALE after 37248 Earlier versions of this standard allowed the -<i>number</i> and +<i>number</i> options. These options are no longer specified by this standard but may be present in some implementations. * ex p355 Insert as a new 2nd para to DESCRIPTION If an operand is '-', the results are unspecified. Append to end of first paragraph of OPTIONS (line 12939) "except for the unspecified usage of '-', and that '+' may be recognized as an option delimiter as well as '-'." In the RATIONALE section on p400 Insert before "Historically" on line 15492 The +<i>command</i> option is no longer specified by this standard but may be present in some implementations. * expand Add a new paragraph to the end of RATIONALE for expand: (16632) Earlier versions of this standard allowed the following form in the SYNOPSIS section: expand [-tabstop][-tab1,tab2,...,tabn][file...] This form is no longer specified by this standard but may be present in some implementations. * more Add in the OPTIONS section to the end of the 1st para at the end of 24927 except that '+' may be recognized as an option delimiter as well as '-'. In the RATIONALE section on page 653 add to the end of line 25536 (line starting "The -p (position)...") The +<i>command</i> option is no longer specified by this standard but may be present in some implementations. * newgrp Add a new paragraph after 25589 If the first argument is '-', the results are unspecified. Append to end of first paragraph of OPTIONS (line 25600) "except for the unspecified usage of '-'." * nice Add to the end of RATIONALE for nice as a new para : Earlier versions of this standard allowed a -increment option. This form is no longer specified by this standard but may be present in some implementations. * renice Change the first paragraph in OPTIONS from The renice utility shall conform to the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines. to The renice utility shall conform to the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines, except for guideline 9." In the OPTIONS section for -g, -p -u change from "Interpret all operands ..." to "Interpret the following operands ..." Add to RATIONALE Earlier versions of this standard allowed the following forms in the SYNOPSIS section: renice nice_value[-p] pid...[-g gid...][-p pid...][-u user...] renice nice_value -g gid...[-g gid...][-p pid...][-u user...] renice nice_value -u user...[-g gid...][-p pid...][-u user...] These forms are no longer specified by this standard but may be present in some implementations. * split Add new paragraph to the end of the RATIONALE for split: Earlier versions of this standard allowed a -line_count option. This form is no longer specified by this standard but may be present in some implementations. *strings Add a new paragraph at the end of DESCRIPTION If the first argument is '-', the results are unspecified. Append to end of first paragraph of OPTIONS (line 34166) "except for the unspecified usage of '-'." Add to end of existing 1st paragraph in the RATIONALE for strings: (line 34235) These options are no longer specified by this standard but may be present in some implementations. * vi Append to end of first paragraph of OPTIONS (line 38101) "except that '+' may be recognized as an option delimiter as well as '-'."