IEEE Standards AssociationCopyright © 2006 IEEE. All rights reserved.
Interpretation Number: 027
Topic: utility extensions violating syntax guidelines
Relevant Sections: XBD 12.2 Utility Syntax Guidelines------------------------------------------------------------------------
7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable):
The Base Definitions volume of IEEE Std 1003.1-2001
------------------------------------------------------------------------
8 Qualifier (e.g. error, omission, clarification required):
3. Clarification required
------------------------------------------------------------------------
9 References in document (e.g. page, clause, figure, and/or table numbers):
Edition of Specification (Year): 2004 Page: 204 Line: 7237-7240 Section: 12.2
Reference xbdbug2.txt ERN 16
------------------------------------------------------------------------
10 Nature of defect (complete, concise explanation of the perceived problem):
Page: 204 Line: 7237-7240 Section: 12.2 This is a request for interpretation of the standard. 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.
------------------------------------------------------------------------
11 Solution proposed by the submitter (optional):
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: --------- 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 '-'."
Back to IEEE Standards Interpretations for IEEE Std 1003.1-2001