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

[Rob Landley]

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

> 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?)

Rob