Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001897 [1003.1(2024)/Issue8] Shell and Utilities Editorial Clarification Requested 2024-12-19 01:56 2024-12-20 07:19
Reporter calestyo View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Interpretation Required  
Name Christoph Anton Mitterer
Organization
User Reference
Section 1.4 Utility Description Defaults; 12.2 Utility Syntax Guidelines
Page Number 2462, ff.; 215 ff.
Line Number 79707, ff; 7753, ff
Interp Status Proposed
Final Accepted Text Note: 0007024
Summary 0001897: forward compatibility of utilities have options that extend POSIX but are not strictly required to support --
Description Hey.

From some private mail exchange with Geoff Clare (and also with his help/ideas, so half of the credit goes to him ;-) ), the following possible hole in the standard became known:

There are utilities (well at least printf), which are as of now not documented as having to conform to the 12.2 Utility Syntax Guidelines and which currently do not have an options.


Page 2462, lines 79707-79710:
> Default Behavior: When this section is listed as "None.", it means
> that the implementation need not support any options. Standard utilities
> that do not accept options, but that do accept operands, shall recognize
> "--" as a first argument to be discarded.

as Geoff told me, requires them to support -- as the first argument (only!) for allowing vendor extensions (like bash's `-v`) respectively future additions to POSIX (like the `-C` already mentioned in future directions).


This means that even in the POSIX-only printf:
   printf -- '%s\n' foo
is expected to print a line with foo, whereas
   printf '%s\n' -- foo
would be two lines (one with -- and the other with --foo).
Similarly:
   printf -v var -- '%s\n' foo
would in a POSIX-only implementation be the format string `-C` and the rest being arguments, but in a vendor implementation it might be the option + value -v var, the format string '%s\n' and argument foo.

The above requirement for the special -- as first argument assures that the utility can be extended. Should that ever be done on the POSIX level, the utility would probably additionally get the requirement for 12.2 Utility Syntax Guidelines conformance.


I then noted that a future addition of e.g. -C to printf, would break e.g.
  printf '%s\n' -C
with Geoff countered with such addition would then also add the 12.2 requirement to the utility’s definition.

But he noted that there is currently no requirement for vendors that already to have extensions to comply with 12.2 guideline 9:
> Guideline 9: All options should precede operands on the command line.

So the utility with extensions beyond POSIX would be allowed to consider the -C in the example above as an option.
Making guideline 9 a requirement for those cases would rule that out, i.e. the utility would have to stop option parsing at the first non-option argument (and optionally support the -- at ANY position as well).


I'd e.g. assume that the env utility is already safe, as it's documented to conform to 12.2 and in thus
   env -i VAR=foo sh -c env
it's already clear that, because of guideline 9 and because of VAR=foo and sh being before the -c, that the -c cannot be an option for env.
Desired Action Resolve the above problem ;-)

Perhaps by appending e.g.:
   and conform to guideline 9 of the 12.2 Utility Syntax Guidelines.
after the "discarded" in line 79710.

Or maybe by doing a bit more?
Realistically, many implementations will allow to mix option and non-option arguments.
So as an alternative to the above one might allow implementation other mean (like stopping at a -- (at any position) or by stopping option parsing at the first non-option argument?


And as a spin off:
- Consider whether the future directions of printf should also include that this would cause requirements for 12.2.
- Consider whether the printf documentation should perhaps be extended to notice that -- might be a first argument and this would the not be the format string (linking to the 1.4 chapter)?


Thanks,
Chris.
Tags tc1-2024
Attached Files

- Relationships

-  Notes
(0007015)
larryv (reporter)
2024-12-19 09:28

 0001897:
Page 2462, lines 79707-79710:
> Default Behavior: When this section is listed as "None.", it means
> that the implementation need not support any options. Standard utilities
> that do not accept options, but that do accept operands, shall recognize
> "--" as a first argument to be discarded.

as Geoff told me, requires them to support -- as the first argument (only!) for allowing vendor extensions (like bash's `-v`) respectively future additions to POSIX (like the `-C` already mentioned in future directions).
I don't think this is the right way to look at it. The requirement to respect first-argument "--" doesn't "allow" vendors to implement extension options; they can do that regardless. What it does is allow applications to protect themselves against said extensions in a conformant manner.


0001897:
Perhaps by appending e.g.:
   and conform to guideline 9 of the 12.2 Utility Syntax Guidelines.
after the "discarded" in line 79710.
This would not make any sense. It would be tantamount to saying, incoherently, that "Utilities that accept operands but not options shall ensure that all options precede all operands."


0001897:
Realistically, many implementations will allow to mix option and non-option arguments.
Can you provide any actual examples of implementations that claim conformance and also behave this way as an extension?


0001897:
So as an alternative to the above one might allow implementation other mean (like stopping at a -- (at any position) or by stopping option parsing at the first non-option argument?
There's nothing to "allow". Implementations that are not required to conform to Utility Syntax Guidelines 9 and 10 can always do so as an extension. The potential issue is that applications currently cannot assume such conformance.

Something like the following might be okay. On page 2463 line 79710, change:
discarded.
to:
discarded; implementations that provide options as an extension should conform to Guidelines 9 and 10 of XBD Section 12.2 (on page 215).
However, this would not provide applications the assurances you seem to desire because I used "should" instead of "shall" because I am not convinced that it is actually possible to legislate extensions like this.


0001897:
And as a spin off:
- Consider whether the future directions of printf should also include that this would cause requirements for 12.2.
- Consider whether the printf documentation should perhaps be extended to notice that -- might be a first argument and this would the not be the format string (linking to the 1.4 chapter)?
You could say similar things about any utility that is not currently required to support options. Why should printf receive special attention on this matter?
(0007024)
geoffclare (manager)
2024-12-19 16:59

 Interpretation response
------------------------

The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
The requirement for recognizing "--" as a first argument to be discarded was intended to apply to all utilities that say "None" in options. However, the use of the phrase "that do not accept options" means that utilities that accept options as an extension were not included.

Applications also rely on being able to pass arguments beginning with '-' after an operand and not have it be treated as an option. For example, printf '%d\n' -2

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 2463 line 79710 section 1.4 Utility Description Defaults, after:
Standard utilities that do not accept options, but that do accept operands, shall recognize "--" as a first argument to be discarded.

add a sentence:
Standard utilities that are not required to accept options but accept them as an extension, and which accept operands, shall conform to Guidelines 9 and 10 of [xref to XBD Section 12.2].
(0007030)
agadmin (administrator)
2024-12-20 07:19

 Interpretation proposed: 20 December 2024

- Issue History
Date Modified Username Field Change
2024-12-19 01:56 calestyo New Issue
2024-12-19 01:56 calestyo Name => Christoph Anton Mitterer
2024-12-19 01:56 calestyo Section => 1.4 Utility Description Defaults; 12.2 Utility Syntax Guidelines
2024-12-19 01:56 calestyo Page Number => 2462, ff.; 215 ff.
2024-12-19 01:56 calestyo Line Number => 79707, ff; 7753, ff
2024-12-19 09:28 larryv Note Added: 0007015
2024-12-19 16:59 geoffclare Note Added: 0007024
2024-12-19 17:00 geoffclare Interp Status => Pending
2024-12-19 17:00 geoffclare Final Accepted Text => Note: 0007024
2024-12-19 17:00 geoffclare Status New => Interpretation Required
2024-12-19 17:00 geoffclare Resolution Open => Accepted As Marked
2024-12-19 17:01 geoffclare Tag Attached: tc1-2024
2024-12-20 07:19 agadmin Interp Status Pending => Proposed
2024-12-20 07:19 agadmin Note Added: 0007030

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker