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

[enh]

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
~$

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".

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?

(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...)

> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net