The following issue has been SUBMITTED. ====================================================================== 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 01:56 UTC ====================================================================== Summary: 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. ====================================================================== 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 ======================================================================
