On Sun, May 19, 2024 at 10:21:42PM +0800, Herbert Xu wrote: > Always reset OPTIND if it is modified by the user, regardless of > its value. I disagree in principle, but I think this is basically fine actually; strictly, we are allowed to do this 98842 If the application sets OPTIND to the value 1, a new set of parameters can be used: either the 98843 current positional parameters or new arg values. Any other attempt to invoke getopts multiple 98844 times in a single shell execution environment with parameters (positional parameters or arg 98845 operands) that are not the same in all invocations, or with an OPTIND value modified to be a 98846 value other than 1, produces unspecified results. but I cannot prove this breaks existing code in the wild.
I mean such code most likely definitely exists,
but I cannot prove this; but even if it does,
it relies on "unspecified" behaviour, which means it
"cannot be assured to be portable across conforming implementations"
such as dash 1 and dash 2.
I still think it should keep working, since it had worked.
While I found at least one changelog entry in DCS saying
"remove unset OPTIND to work around broken dash shell"
by searching for "unset.*OPTIND\b",
searching "OPTIND=[^01]" gives me heaps of OPTIND=digit
and OPTIND=expression users, but most of them are explicit bash users;
the first one with /bin/sh is
https://sources.debian.org/src/sptk/3.9-3/debian/scripts/raw2wav/?hl=74#L74
reading
OPTIND=0
OPT=""
for i in "$@"
do
OPTIND=`expr $OPTIND + 1`
if [ "$OPT" = "" ]
then
OPTARG=""
but this program doesn't use getopts.
This turns "unset OPTIND must work but doesn't"
+ "OPTIND=asd is invalid but probably shouldn't be"
+ "OPTIND=3 makes getopts parse the third argument (as a happy
accident)"
into "unset OPTIND works"
+ "OPTIND=asd works (and restarts getopts as a happy accident)"
+ "OPTIND=3 restarts getopts (as a happy accident)".
So, overall, reasonable, if a tad solomonic.
signature.asc
Description: PGP signature
