A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1897 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1897 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New 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: --- Final Accepted Text: ====================================================================== Date Submitted: 2024-12-19 01:56 UTC Last Modified: 2024-12-19 09:28 UTC ====================================================================== Summary: forward compatibility of utilities have options that extend POSIX but are not strictly required to support -- ======================================================================
---------------------------------------------------------------------- (0007015) larryv (reporter) - 2024-12-19 09:28 https://austingroupbugs.net/view.php?id=1897#c7015 ---------------------------------------------------------------------- https://austingroupbugs.net/view.php?id=1897:<blockquote>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).</blockquote>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. https://austingroupbugs.net/view.php?id=1897:<blockquote>Perhaps by appending e.g.: and conform to guideline 9 of the 12.2 Utility Syntax Guidelines. after the "discarded" in line 79710.</blockquote>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." https://austingroupbugs.net/view.php?id=1897:<blockquote>Realistically, many implementations will allow to mix option and non-option arguments.</blockquote>Can you provide any actual examples of implementations that claim conformance and also behave this way as an extension? https://austingroupbugs.net/view.php?id=1897:<blockquote>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?</blockquote>There's nothing to "allow". <i>Implementations</i> 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 <i>applications</i> currently cannot assume such conformance. Something like the following might be okay. On page 2463 line 79710, change:<blockquote>discarded.</blockquote>to:<blockquote>discarded; implementations that provide options as an extension should conform to Guidelines 9 and 10 of XBD Section 12.2 (on page 215).</blockquote>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. https://austingroupbugs.net/view.php?id=1897:<blockquote>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)?</blockquote>You could say similar things about any utility that is not currently required to support options. Why should <i>printf</i> receive special attention on this matter? 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 ======================================================================
