Hi,
On 29/01/2021 18:25, earnestly wrote:
In this example dash will repeatedly append 'attr=foo' to the list of
parameters in an infinite loop:
#!/bin/dash -x
while getopts :a: arg -a foo -a bar; do
case $arg in
a) set -- "$@" attr="$OPTARG"
esac
done
shift "$((OPTIND - 1))"
Instead I expected this to result in parameter list containing
'attr=foo' and 'attr=bar'.
You are correct in your expectation, I believe: ending the loop after
processing both arguments is what your script should do.
The reason that dash is behaving the way it does is that dash resets the
getopts state when the positional arguments are changed by the set or
shift commands. The getopts state is also reset when the positional
arguments are changed because of a function call, but restored after the
function returns. This is something shared across ash-based shells; you
will also find it in FreeBSD's /bin/sh, and if I am not misreading the
code, NetBSD's /bin/sh as well.
Although there are certainly cases where this behaviour is useful,
especially the part where it saves and restores state for function
calls, there are also where it is not, such as yours. Additionally, it
appears to be in conflict with POSIX, which requires the getopts state
to be preserved as long as it continues to be called with the same
arguments: only resetting OPTIND to 1 is specified to reset the state to
allow arguments to be parsed anew.
I would suggest that if this is changed to conform to POSIX, a
non-standard method should remain available to allow shell functions to
use getopts internally, including when the getopts loop in the function
calls other functions that themselves use getopts, to ensure that any
existing scripts broken by the change can be easily updated. One way to
achieve that could be to special-case "local OPTIND=1" so that when the
function returns, it restores not just the value of OPTIND, but uses
that moment to additionally restore the extra internal state.
Cheers,
Harald van Dijk
