From: Harald van Dijk <harald@gigawatt.nl>
To: наб <nabijaczleweli@nabijaczleweli.xyz>,
"Herbert Xu" <herbert@gondor.apana.org.au>
Cc: dash@vger.kernel.org
Subject: Re: [PATCH] var: Do not add 1 to return value of strchrnul
Date: Wed, 4 Jan 2023 16:50:34 +0000 [thread overview]
Message-ID: <b00cdaa5-0072-392c-3cf7-184aa8e45ae3@gigawatt.nl> (raw)
In-Reply-To: <20230104160526.7vuq3s2ivqaaot4l@tarta.nabijaczleweli.xyz>
On 04/01/2023 16:05, наб wrote:
> Hi!
>
> On Wed, Jan 04, 2023 at 10:12:36PM +0800, Herbert Xu wrote:
>> On Wed, Jan 04, 2023 at 01:54:21PM +0100, наб wrote:
>>> AFAICT, after trawling through the Issue 8 Draft 2.1,
>>> there are no special provisions for unset/OPTIND,
>> Well it says this regarding OPTIND:
>>
>> : If the application sets OPTIND to the value 1, a new set of parameters
>> : can be used: either the current positional parameters or new arg
>> : values. Any other attempt to invoke getopts multiple times in a single
>> : shell execution environment with parameters (positional parameters
>> : or arg operands) that are not the same in all invocations, or with an
>> : OPTIND value modified to be a value other than 1, produces unspecified
>> : results.
>>
>> Unsetting OPTIND ought to do the same thing as setting it to "",
> On the basis of? Those are fundamentally unrelated operations,
> and when they are to do the same thing, this is explicitly noted.
On the basis of common sense, keeping in mind that different people's
ideas of common sense will be different. In this one, I'm tempted to
agree with Herbert Xu, $OPTIND would expand to an empty string whether
OPTIND is unset or set to an empty string, assuming set -u is not in
effect, so for the purpose of the getopts command it would be good for
it to behave the same way there too.
> Additionally, this is a description of /getopts/, and therefore only
> applies if you do "OPTIND=dupa; getopts ..." ‒ the getopts call is
> unspecified.
>
> /Any/ operation on OPTIND is legal, and the current behaviour is wrong
> (but it seems that no-one has actually cared) ‒ POSIX defines this in
> terms of getopts inspecting OPTIND when it's run.
Indeed, but dash isn't the only shell that behaves this way (posh does
too) and I'm not sure whether this is what POSIX intends to specify. I
agree with your interpretation of what POSIX actually says, but it would
be good for POSIX to reword it regardless of what is intended to be
clearer that this case was actually considered.
Personally, I do think it is better if shells allow assigning arbitrary
values to OPTIND, including unsetting it, and only have the getopts
command raise an error if the value is non-numeric, but that is my
personal opinion and I don't see much of a problem if dash decides to go
the other way, unless POSIX makes it explicit that it is not permitted
for shells to do this. FWIW, I did make that change for my version,
<https://github.com/hvdijk/gwsh/commit/0df0ba33748eb3881b07cb724fd4fa54422ef2bc>,
if that change is desired for dash it is easy to apply.
Cheers,
Harald van Dijk
next prev parent reply other threads:[~2023-01-04 16:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 2:31 [PATCH] options: don't error when unsetting OPTIND наб
2022-12-14 14:18 ` Michael Greenberg
2022-12-14 17:49 ` Steffen Nurpmeso
2022-12-14 22:36 ` Michael Greenberg
2022-12-14 23:07 ` наб
2022-12-15 18:39 ` Michael Greenberg
2023-01-03 9:39 ` [PATCH] var: Do not add 1 to return value of strchrnul Herbert Xu
2023-01-03 9:51 ` [v2 PATCH] " Herbert Xu
2023-01-03 12:26 ` [PATCH] " наб
2023-01-04 9:59 ` Herbert Xu
2023-01-04 12:54 ` наб
2023-01-04 14:12 ` Herbert Xu
2023-01-04 16:05 ` наб
2023-01-04 16:50 ` Harald van Dijk [this message]
2024-05-19 11:19 ` [PATCH] options: Always reset OPTIND in getoptsreset Herbert Xu
2024-05-19 13:23 ` Harald van Dijk
2024-05-19 14:21 ` [v2 PATCH] " Herbert Xu
2024-05-21 14:38 ` наб
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=b00cdaa5-0072-392c-3cf7-184aa8e45ae3@gigawatt.nl \
--to=harald@gigawatt.nl \
--cc=dash@vger.kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=nabijaczleweli@nabijaczleweli.xyz \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).