dash.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Harald van Dijk <harald@gigawatt.nl>
To: earnestly <zibeon@gmail.com>, dash@vger.kernel.org
Subject: Re: getopts appears to not be shifting $@ when consuming options
Date: Sat, 30 Jan 2021 15:31:34 +0000	[thread overview]
Message-ID: <7853ad4d-0eaf-3e91-d5bd-c7a969ed447f@gigawatt.nl> (raw)
In-Reply-To: <c5b375e0-e6b4-df94-3dbd-26c05ecbe688@gigawatt.nl>

On 29/01/2021 20:15, Harald van Dijk wrote:
> I would suggest that if this is changed to conform to POSIX, a 
> non-standard method should remain available to allow shell functions to 
> use getopts internally, including when the getopts loop in the function 
> calls other functions that themselves use getopts, to ensure that any 
> existing scripts broken by the change can be easily updated. One way to 
> achieve that could be to special-case "local OPTIND=1" so that when the 
> function returns, it restores not just the value of OPTIND, but uses 
> that moment to additionally restore the extra internal state.

I have found that "local OPTIND=1" already works that way in bash, 
restoring upon function return not only the value of OPTIND but also the 
extra internal extra state. It is designed to work like that, not just a 
happy accident: it is listed as a new feature of 4.4. Because of that, 
if something like this is implemented, this would probably be the best 
syntax to use.

I have also found that this is easy to implement: currently, 
getoptsreset() just sets the internal state (shellparam.optind and 
shellparam.optoff) based on the text value of OPTIND. Instead, if:
- var.h defines a new flag to indicate that special hidden data is
   present past the end of OPTIND's text value,
- getopts() builds its own buffer, including the extra hidden data, and
   calls setvareq() directly with that special flag rather than relying
   on setvarint(),
- getoptsreset() checks it to either set the internal state as before
   or restore the internal state, depending on whether that special flag
   is set,
everything just works with no special casing needed in the 
implementation of the "local" command. The net result is even a small 
reduction in code size.

I am only posting a description of the changes rather than a patch or a 
link to a patch because I implemented this in my shell (a fork of dash), 
not dash itself, and the changes as I implemented them cannot be applied 
to dash without some modifications.

Cheers,
Harald van Dijk

  reply	other threads:[~2021-01-30 16:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29 18:25 getopts appears to not be shifting $@ when consuming options earnestly
2021-01-29 20:15 ` Harald van Dijk
2021-01-30 15:31   ` Harald van Dijk [this message]
2021-01-29 20:36 ` Jilles Tjoelker
2021-01-29 21:19   ` Harald van Dijk
2021-01-29 22:25   ` earnestly
2021-01-30  6:39     ` Vladimir N. Oleynik
2021-01-30  7:36     ` Vladimir N. Oleynik

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=7853ad4d-0eaf-3e91-d5bd-c7a969ed447f@gigawatt.nl \
    --to=harald@gigawatt.nl \
    --cc=dash@vger.kernel.org \
    --cc=zibeon@gmail.com \
    /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).