Martijn Dekker <[email protected]> wrote, on 14 Jun 2019: > > The text only explicitly specifies the value 1 of OPTIND at initialisation > time, and it only explicitly requires it to be numeric at the end of option > processing. > > Yes, it would intuitively make sense to assume the value is required to be > numeric in between init and end of processing as well, but the text does not > state this explicitly. > > And implementers run into a bit of problem: a purely numeric OPTIND is > insufficient to track the state of short options as several options may be > combined into a single argument. > > So that leaves shells with two options: adhere to the intuitive > interpretation of the text and maintain an invisible extra state, which is a > botch, but that's what the majority does. Or store the extra state in OPTIND > as well, rendering it potentially non-numeric until the end of option > processing, but otherwise resulting in a cleaner and more transparent > implementation. I can't find anything in the text that actually prohibits > this.
It says "the index of the next argument". Clearly this means the index references an argument, not some position within an argument. It's true that it doesn't say it has to be a numeric index, but given that it starts at 1 that's obviously the intention. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
