On Fri, Jan 29, 2021 at 06:25:25PM +0000, 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'. Hmm, that's pretty clever. By passing the parameters to be parsed to the getopts command instead of via $@, it is possible to modify $@ without violating POSIX's rule that only allows parsing a single unmodified set of parameters (unless getopts is reset via OPTIND=1). Unfortunately, dash and FreeBSD sh reset the getopts state when the positional parameters are modified via set or shift. They probably do this to avoid use after free and out of bounds memory access when a script violates POSIX's rule. However, when the parameters come from the getopts command, there is no violation of the rule and no memory unsafety problem. > This works in all shells I have been able to test with the exception of > busybox sh: > * sh (bash) > * bash (All versions from 1.14 through 5.1.4) > * mksh (MIRBSD KSH R59 2020/05/16) > * ksh (93u+) > * zsh (5.8) > * zsh --emulate sh > * heirloom-sh (bourne) > The only workaround I've found is to explicitly use `shift 2` in the a) > case and obviate the final shift using OPTIND. This will unfortunately > break every other shell. Since you need code to "un-eval" a list of parameters to construct the getopts command above in a general case, a better workaround would be to use that code to construct the attr="$OPTARG" list. If your actual code is more like: set -- -a foo -a bar # for testing while getopts :a: arg; do ... then the script violates the rule I mentioned, and has unspecified results. -- Jilles Tjoelker