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: New Name: Robert Elz Organization: User Reference: Section: XCU 3 / getopts Page Number: 2955 - 2959 Line Number: 98803 - 98966 Final Accepted Text: ====================================================================== Date Submitted: 2023-10-22 06:14 UTC Last Modified: 2023-11-13 20:16 UTC ====================================================================== Summary: getopts specification needs fixing (multiple issues) ======================================================================
---------------------------------------------------------------------- (0006569) kre (reporter) - 2023-11-13 20:16 https://austingroupbugs.net/view.php?id=1784#c6569 ---------------------------------------------------------------------- Re: https://austingroupbugs.net/view.php?id=1784#c6568 The first paragraph cannot possibly be correct, unix programs have been using multiple flag options after a single '-' since about when (perhaps exactly when, 'twas before my time) they were invented. "ls -al" is a simple example that has been with us forever. There is no way that anyone, anywhere, ever, would have even considered requiring that to be "ls -a -l". Further, it is getopts' role to parse the option args (and was getopt's before that, as much as it was able) expecting the shell to parse them (which it would need to do to distinguish between a: and al as the optstring, which varies how ls -al would need to be treated) and then invoke getopts to parse them again would be absurd. The second paragraph (2nd sentence in particular, we can't do the first, as there is no existing standard to document) I almost agree with - except that we write "unspecified value" not "opaque" (the meaning is almost the same), and that we must require OPTIND to contain a string representing an integer after getopts has returned "no more" (ie: exit status 1), as we must be able to do "shift $(( OPTIND - 1 ))" In general, the only time a script should reference OPTIND is after getopts has indicated the options are done (and with that in mind, it might be worth adding a note in the application usage section advising against a "break" out of a while getopts ... ; do ; done loop, the loop should be allowed to terminate naturally) and it can be set to 1 (OPTIND=1) before the getopts loop starts to reinit things. 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 ======================================================================
