From: "Francisco de Zuviría Allende" <franciscodezuviria@gmail.com>
To: dana <dana@dana.is>
Cc: Bart Schaefer <schaefer@brasslantern.com>,
"zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: [BUG] getopts OPTIND
Date: Tue, 9 Jan 2018 22:32:38 -0300 [thread overview]
Message-ID: <CA++-COysKY-+R43kHkr=47BDn9V87dAi3RzZAnEaEi3RftrE3A@mail.gmail.com> (raw)
In-Reply-To: <043D5A33-6258-4C87-9505-4AEBE17FA9FC@dana.is>
Such quick, much wow!
On Jan 9, 2018 8:58 PM, "dana" <dana@dana.is> wrote:
>
> On 9 Jan 2018, at 16:57, Bart Schaefer <schaefer@brasslantern.com> wrote:
> >There's a whole thread from 2015 related to this, beginning with workers/35317
>
OK, I just read workers/35317
and also the previous thread http://www.zsh.org/mla/workers//2015/msg00196.html
and also the previous from 2007 http://www.zsh.org/mla/users/2007/msg01191.html
2 key responses from Peter Stephenson:
2007:
> This is the way you'd normally use it: you don't know how many options
> there are, if any, until getopts returns 1.
>
> However, it's still a bit fishy. The internal option index handling logic
> has always been a bit curious; I've lost count of the number of bugs we've
> had in it.
And also
On Thu, 28 May 2015 18:17:40 +0100
Peter Stephenson <p.stephenson@xxxxxxxxxxx> wrote:
> This is documented behaviour (well, sort of -- the documentation didn't
> say quite what we actually do) so this needs another compatibility fix.
> POSIX_BUILTINS seems appropriate.
(and then submits a cool patch)
I checked man zshbuiltins
getopts optstring name [ arg ... ]
(...)
The first option to be examined may be changed by
explicitly assigning to OPTIND. OPTIND has an initial value of
1, and is normally set to 1 upon entry to a
shell function and restored upon exit (this is disabled by the
POSIX_BUILTINS option).
and man zshoptions
POSIX_BUILTINS <K> <S>
(...)
Furthermore, the getopts builtin behaves in a
POSIX-compatible fashion in that the associated variable OPTIND is
not made local to functions.
Now here things get funky. If I try this:
(
testfunc() {
echo POSIX_BUILTINS is $options[posixbuiltins]
echo $*;
for i in 1 2 3 4; do
echo "OPTIND is $OPTIND, `(shift "$(($OPTIND - 1))"; echo
next $1)`";
echo 'I do getopts :a: varname'; getopts ':a:' varname;
done
}
(
setopt POSIX_BUILTINS
testfunc -a -w -e -r
)
(
unsetopt POSIX_BUILTINS
testfunc -a -w -e -r
)
)
I get:
POSIX_BUILTINS is on
-a -w -e -r
OPTIND is 1, next -a
I do getopts :a: varname
OPTIND is 3, next -e
I do getopts :a: varname
OPTIND is 3, next -e
I do getopts :a: varname
OPTIND is 4, next -r
I do getopts :a: varname
POSIX_BUILTINS is off
-a -w -e -r
OPTIND is 1, next -a
I do getopts :a: varname
OPTIND is 3, next -e
I do getopts :a: varname
OPTIND is 3, next -e
I do getopts :a: varname
OPTIND is 4, next -r
I do getopts :a: varname
hmmmmmmm... I's it a bug?
> Well, i'm not sure about POSIX correctness, but for whatever it's worth, i can
> confirm that all of the following are in agreement as to how it should behave:
>
> ash (BusyBox)
> bash
> dash
> ksh93
> mksh
> posh
>
I think there are 2 things to discuss, one is this (possible) bug.
The other is if POSIX_BUILTINS should be on by default or not.
If off by default, New users will get bugs in their code if they
migrate from bash
If on by default, downstream projects will get bugs in their working code
This options does other things as well:
When this option is set the command builtin can be used
to execute shell builtin commands. Parameter assignments
specified before shell functions and special
builtins are kept after the command completes unless the special
builtin is prefixed with the command builtin. Special
builtins are ., :, break, continue, declare, eval, exit,
export, integer, local, readonly, return, set, shift,
source, times, trap and unset.
In addition, various error conditions associated with
the above builtins or exec cause a non-interactive shell to
exit and an interactive shell to return to its top-level
processing.
So this is a broather subject and may be better discussed in a new
thread with a suitable title
next prev parent reply other threads:[~2018-01-10 1:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 16:22 Francisco de Zuviría Allende
2018-01-09 22:48 ` dana
2018-01-09 22:57 ` Bart Schaefer
2018-01-09 23:58 ` dana
2018-01-10 1:32 ` Francisco de Zuviría Allende [this message]
2018-01-10 9:05 ` Peter Stephenson
2021-04-13 23:28 ` dana
2021-04-14 13:04 ` [BUG] getopts OPTIND - yash's behaviour Daniel Shahaf
2021-04-14 13:08 ` [BUG] getopts OPTIND Daniel Shahaf
2021-04-18 5:16 ` dana
2021-04-20 21:31 ` Daniel Shahaf
2021-05-03 23:38 ` dana
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='CA++-COysKY-+R43kHkr=47BDn9V87dAi3RzZAnEaEi3RftrE3A@mail.gmail.com' \
--to=franciscodezuviria@gmail.com \
--cc=dana@dana.is \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
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).