[Toybox] Subject: [PATCH] Add getopt(1).

[enh]

On Sat, Nov 23, 2019, 07:22 Rob Landley <rob at landley.net> wrote:

>
>
> On 11/22/19 10:17 AM, enh wrote:
> > On Fri, Nov 22, 2019 at 5:02 AM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 11/22/19 6:56 AM, Rob Landley wrote:
> >>> On 11/21/19 4:13 PM, enh via Toybox wrote:
> >>>> Includes new tests.
> >>>> ---
> >>>>  lib/portability.h     |   3 ++
> >>>
> >>> Applied, by why add this #include to portability.h when it's not in an
> #ifdef?
> >>> The main #includes are in toys.h.
> >>
> >> Also, would someone please explain why posix-2008 has "getopts" with an
> s:
> >>
> >>
> https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/utilities/getopts.html
> >>
> >> But the bash builtin and util-linux command are both "getopt" without
> an s? (And
> >> gratuitously stomping man 3 getopt with man 1 getopt?)
> >
> > are you sure? my bash has getopts built in and an external getopt.
> >
> > ~$ type getopts
> > getopts is a shell builtin
> > ~$ type getopt
> > getopt is /usr/bin/getopt
> > ~$
>
> It's worse than that, the bash "help" command replies (with the same text)
> for
> both getopt and getopts. (But the first line calls the command getopts.)
>
> > the same is true of mksh too. haven't looked at any other shells.
> >
> >> I notice this new implementation doesn't link to posix as its spec in
> the header
> >> block, I'm guessing they're different commands?
> >
> > mostly, yes. the comment in the getopt.c source about "legacy" mode?
> > POSIX getopts is a subset even of that. legacy mode is more
> > complicated because you have to deal with cases like "mostly using new
> > options, but missing -o or an early OPTSTR, so steal the first app
> > argument".
>
> Looking at the .c of the new command I was going "ooh, that's small and
> simple,
> I can probably promote that in an hour of reading and pondering", but then
> scratch the surface and it's dragging in this whole parallel libc
> implementation...
>
> 0000000000001097 T _getopt_internal_r
>

The only real point of getopt(1) over the getopts built-in is long options.
That's all I've seen it used for in practice. It does seem like folks know
about getopts, and they do use it when short options are all they want.

> on the bright side, getopts is probably two lines of C in the shell
> > --- basically just a call to non-long getopt(3), although getopts is
> > also subject to a few extra shell variables that don't mean anything
> > to getopt(1). that might be the reason why even bash's getopts doesn't
> > have all the extra stuff that's in a current getopt(1) added to it?
>
> I have no idea what the difference is here and need to dig it seems.
>
> > (there are actually orders of magnitude more references to getopts
> > than getopt in the Android build, but that's covered by bash for the
> > time being...)
>
> While it was on my todo list for toysh, I'm not sure swallowing a large
> lump of
> gnu/glibc bespoke nonsense actually helps advance this ball. (Although I
> assume
> bionic copied an implementation from netbsd?)
>

Correct. Apple's libc did too, so the getopt tests pass there too --- I
tested yesterday when I was going through all the macos_defconfig tests.

Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20191123/7604dbec/attachment-0001.htm>