Re: [PATCH] var: Do not add 1 to return value of strchrnul

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux