From: Harald van Dijk <harald@gigawatt.nl>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: martijn@inlv.org, dash@vger.kernel.org
Subject: Re: getopts doesn't properly update OPTIND when called from function
Date: Mon, 01 Jun 2015 19:30:46 +0200 [thread overview]
Message-ID: <556C96C6.5030600@gigawatt.nl> (raw)
In-Reply-To: <20150601062905.GB10460@gondor.apana.org.au>
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 that would make the result undefined or unspecified either.
>> I do think the script is valid, and the results in dash should match
>> those of other shells.
>
> The bash behaviour makes it impossible to call shell functions
> that invoke getopts while in the middle of an getopts loop.
>
> IMHO the dash behaviour makes a lot more sense since a function
> always brings with it a new set of parameters. That plus the
> fact that this behaviour has been there since day one makes me
> reluctant to change it since the POSIX wording is not all that
> clear.
True. Given that almost no shell supports that anyway, there can't be
too many scripts that rely on it, but I did warn about the risk of
breaking another type of existing scripts as well, I agree that's a real
concern.
One thing that doesn't really make sense, though: if the getopts
internal state is local to a function, then OPTIND and OPTARG really
should be too. Because they aren't, nested getopts loops already don't
really work in a useful way in dash, because the inner loop overwrites
the OPTIND and OPTARG variables. While OPTARG will typically be checked
right at the start of the loop, before any inner loop executes, OPTIND
is typically used at the end of the loop, in combination with the shift
command. The current behaviour makes the OPTIND value in that case
unreliable.
So either way, I think something should change. But if you prefer to get
clarification first about the intended meaning of the POSIX wording,
that certainly seems reasonable to me.
> Cheers,
next prev parent reply other threads:[~2015-06-01 17:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-28 18:54 getopts doesn't properly update OPTIND when called from function Martijn Dekker
2015-05-28 22:39 ` Harald van Dijk
2015-05-29 2:58 ` Herbert Xu
2015-05-29 5:50 ` Harald van Dijk
2015-06-01 6:29 ` Herbert Xu
2015-06-01 17:30 ` Harald van Dijk [this message]
2015-06-01 22:10 ` Jilles Tjoelker
2015-06-02 0:21 ` Harald van Dijk
2015-06-04 19:56 ` Martijn Dekker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=556C96C6.5030600@gigawatt.nl \
--to=harald@gigawatt.nl \
--cc=dash@vger.kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=martijn@inlv.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).