Harald van Dijk schreef op 29-05-15 om 00:39:
A quick patch to make sure it is global, and isn't reset when it
shouldn't or doesn't need to be, is attached. You can experiment with
it, if you like.
I've been using dash with this patch since you posted it, and it works
like a charm (including
On Fri, May 29, 2015 at 07:50:09AM +0200, Harald van Dijk wrote:
But the test script in this thread does invoke getopts with
parameters that are the same in all invocations, and without
modifying OPTIND. I don't see anything else in the normative
sections that would make the result undefined
On 01/06/2015 08:29, Herbert Xu wrote:
On Fri, May 29, 2015 at 07:50:09AM +0200, Harald van Dijk wrote:
But the test script in this thread does invoke getopts with
parameters that are the same in all invocations, and without
modifying OPTIND. I don't see anything else in the normative
sections
On Mon, Jun 01, 2015 at 07:30:46PM +0200, Harald van Dijk wrote:
On 01/06/2015 08:29, Herbert Xu wrote:
On Fri, May 29, 2015 at 07:50:09AM +0200, Harald van Dijk wrote:
But the test script in this thread does invoke getopts with
parameters that are the same in all invocations, and without
On 28/05/2015 20:54, Martijn Dekker wrote:
I'm writing a shell function that extends the functionality of the
'getopts' builtin. For that to work, it is necessary to call the
'getopts' builtin from the shell function.
The POSIX standard specifies that OPTIND and OPTARG are global
variables,
On 29/05/2015 04:58, Herbert Xu wrote:
Harald van Dijk har...@gigawatt.nl wrote:
That isn't the problem, not exactly anyway. The problem is that getopts
is required to keep internal state separately from the OPTIND variable
(a single integer is insufficient to track the progress when multiple
