On 2019-06-30, Evan Gates <evan.gates_AT_gmail.com> wrote:
> On Fri, Jun 28, 2019 at 3:08 AM Michael Forney <mforney_AT_mforney.org> wrote:
>>
>> Then, maybe something like the following would work for those cases.
>>
>> ARGBEGIN {
>> default:
>> goto done;
>> } ARGEND
>> done:
>
> Seeing as we have more confusion and bugs to deal with in argument
> handling, perhaps now is a time to revist the conversation surrounding
> getopt(3p)? There is a POSIX mandated libc function that parses POSIX
> options following the utility syntax guidelines. I strongly suggest
> using it. I know there has been pushback in the past but it's a
> portable option that solves our exact problems. This is why it exists.
> It's already part of libc. We should stop avoiding it in favor of a
> difficult to read block of macros that have trouble dealing with corner
> cases. Removing arg.h simplifies sbase code and maintenance and helps
> break the cycle of NIH that we often fall into.
I'm okay with switching to getopt(3), but also note that the current
arg.h is probably more complicated than it needs to be. Here's a
version I rewrote that I've been using in my own projects:
https://git.sr.ht/~mcf/samurai/blob/master/arg.h
I agree that getopt(3) would probably be better at handling the corner
cases. Yesterday I was planning to check that tools behaved correctly
with argv = { NULL }. The first thing I tried was rm(1), which tried
to remove files corresponding to my environment (i.e.
"SHELL=/bin/ksh"). Yikes!
I am also not sure how getopt(3) could be used to handle the tricky
cases I mentioned, like printf(1). It doesn't have any options, but
still needs to support `--` and treat arguments that start with `-` as
operands rather than printing a usage message.
Received on Mon Jul 01 2019 - 06:20:43 CEST