A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1784 ====================================================================== Reported By: kre Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1784 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: Resolved Name: Robert Elz Organization: User Reference: Section: XCU 3 / getopts Page Number: 2955 - 2959 Line Number: 98803 - 98966 Final Accepted Text: See https://austingroupbugs.net/view.php?id=1784#c6600. Resolution: Accepted As Marked Fixed in Version: ====================================================================== Date Submitted: 2023-10-22 06:14 UTC Last Modified: 2023-12-15 00:05 UTC ====================================================================== Summary: getopts specification needs fixing (multiple issues) ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0000191 getopt and leading + in optstring ======================================================================
---------------------------------------------------------------------- (0006610) kre (reporter) - 2023-12-15 00:05 https://austingroupbugs.net/view.php?id=1784#c6610 ---------------------------------------------------------------------- Re https://austingroupbugs.net/view.php?id=1784#c6607 https://austingroupbugs.net/view.php?id=1784#c6608 and https://austingroupbugs.net/view.php?id=1784#c6609 I know what you're trying to say in that paragraph at lines 98868... but the wording is still poor. "The next element in the parameter list" is just ordinary English text, if you wanted to make that be something special, so that a reader would associated it with the earlier text, you'd need to either define a term to represent this object, or at the very least set it off using some stylistic mechanism (quotes, italics, ...) - in both cases. It is worse, because the sentence that starts "Note that" is in the paragraph about where the parameters come from, and it is natural to read the "in this case" as referring to the case where the params are given on the getopts command line, rather than those that come from the positional params, which is not what is intended. It would be improved if that were a separate paragraph (but that alone is not really enough). I'd prefer it if instead of "next argument in the parameter list need not exist", it simply said "there need not be any parameters in the list following the last option or option-argument processed" and then in the earlier bullet points, instead of making OPTIND the index of the next element of the parameter list, if it exists, just define it to be one more than the index of the last param consumed by the processing (which necessarily must exist, and hence avoids the philosophical issue of how something which does not exist gets numbered, and hence the need to specially handle that case). I really see no need for obscure wording, when alternates are just as good, and clearer. Wrt the other issue - the sentence being added (currently the last sentence in https://austingroupbugs.net/view.php?id=1784#c6600) is OK, but is unrelated to the issue I have. https://austingroupbugs.net/view.php?id=1784#c6608 makes things quite clear I think, and requires a change of the wording. What is clear from that note, is that the standards developers decided to leave '+' unspecified. That's fine, and if the text said that, then it would be OK. But it doesn't. It says that "the standard intentionally"... which is a different thing entirely. Believe it or not, the standards developers, and the standard, are two different things. Since no-one has even attempted to show any normative text in the standard which is "intentionally allowing" the use of the leading plus-sign in the getopts optstring, then I conclude that it simply does not exist. If you were to take the opinion that anything which is unspecified is intentionally allowing any kind of behaviour, then you're opening a whole bunch of cans of worms all over the place, which would make it very difficult to ever add anything to the standard, because all of those unspecified items can be argued to be intentionally allowing whatever I want them to mean - hence blocking any different interpretation in the future. Again, this is just wording, not the intended meaning, I believe, so I really cannot understand the insistence on not using words that are clearer, just because some other words currently exist. You can also compare the words added to getopt() by https://austingroupbugs.net/view.php?id=191 (which are reasonable) which were quoted in https://austingroupbugs.net/view.php?id=1784#c6608 where it says that the use of a leading <plus-sign> in getopts is unspecified. That's fine. But what the rationale in getopts is saying is that the standard is intentionally allowing implementations to use a leading '+' - which is an entirely different thing to say. Please, just fix the wording! Issue History Date Modified Username Field Change ====================================================================== 2023-10-22 06:14 kre New Issue 2023-10-22 06:14 kre Name => Robert Elz 2023-10-22 06:14 kre Section => XCU 3 / getopts 2023-10-22 06:14 kre Page Number => 2955 - 2959 2023-10-22 06:14 kre Line Number => 98803 - 98966 2023-10-22 06:40 kre Tag Attached: issue8 2023-10-28 05:08 Don Cragun Relationship added related to 0001535 2023-10-28 05:10 Don Cragun Relationship added related to 0001393 2023-10-28 05:10 Don Cragun Relationship added parent of 0000351 2023-10-28 05:19 kre Note Added: 0006555 2023-10-28 05:36 kre Note Added: 0006556 2023-10-28 06:25 Don Cragun Note Added: 0006558 2023-10-28 06:27 Don Cragun Relationship deleted related to 0001535 2023-10-28 06:28 Don Cragun Relationship deleted related to 0001393 2023-10-28 06:34 Don Cragun Relationship deleted parent of 0000351 2023-10-28 06:34 kre Note Edited: 0006556 2023-11-13 18:09 shware_systems Note Added: 0006568 2023-11-13 20:16 kre Note Added: 0006569 2023-11-14 09:44 geoffclare Tag Detached: issue8 2023-11-15 22:23 salewski Issue Monitored: salewski 2023-12-11 17:37 geoffclare Note Added: 0006598 2023-12-11 17:41 Don Cragun Note Added: 0006599 2023-12-11 17:50 Don Cragun Note Added: 0006600 2023-12-11 17:55 Don Cragun Note Edited: 0006600 2023-12-11 17:58 Don Cragun Note Edited: 0006600 2023-12-11 17:59 Don Cragun Status New => Resolved 2023-12-11 17:59 Don Cragun Resolution Open => Accepted As Marked 2023-12-11 18:01 Don Cragun Final Accepted Text => See https://austingroupbugs.net/view.php?id=1784#c6600. 2023-12-11 18:02 Don Cragun Tag Attached: issue8 2023-12-11 19:22 Don Cragun Note Deleted: 0006599 2023-12-11 23:41 kre Note Added: 0006602 2023-12-11 23:42 kre Note Edited: 0006602 2023-12-11 23:52 kre Note Added: 0006603 2023-12-12 09:25 geoffclare Note Added: 0006604 2023-12-12 09:25 geoffclare Note Edited: 0006604 2023-12-12 21:22 kre Note Added: 0006606 2023-12-14 07:05 Don Cragun Note Added: 0006607 2023-12-14 09:46 geoffclare Note Added: 0006608 2023-12-14 09:47 geoffclare Relationship added related to 0000191 2023-12-14 16:44 Don Cragun Note Edited: 0006600 2023-12-14 16:50 Don Cragun Note Added: 0006609 2023-12-14 16:51 Don Cragun Note Edited: 0006600 2023-12-14 16:53 Don Cragun Note Edited: 0006609 2023-12-15 00:05 kre Note Added: 0006610 ======================================================================
