On Thursday, February 29th, 2024 at 19:03, Rob Landley <r...@landley.net> wrote: > On 2/28/24 18:23, Oliver Webb via Toybox wrote: > > > I've been looking at some of the other pending commands, And found a getopt > > implementation from 2017 by AOSP. > > Looking at the source code, it doesn't seem unclean, nor overly large > > (about 100 lines). > > It does use getopt_long_only, a GNU extension of glibc, but musl has that > > so it will work > > on both glibc and musl. It is GNU compatible too, all test cases pass (even > > for TEST_HOST). > > > It's mostly that: > > A) I'm not a shell getopt user and haven't put in the focus to come up to > speed > on it yet, > > B) the shell has a "getopts" (plural) builtin that I need to write, but which > this doesn't share code with. And LOTS of stuff confuses the two. (There's a > comment in this source about "BSD getopts", when this is "getopt".) Of COURSE > the semantics of the two are subtly different. > > C) I'd really wanted to get it to use lib/args.c instead of having two > getopt() > implementations in toybox (one from lib/ and one pulled in from libc). > > Sigh. That said, I've been sitting on this for a long time without doing > anything about it, and the perfect is the enemy of the good. > > The libc version isn't bad, it just bloats the static binary pulling in two > implementations of approximately the same code. I don't know if switching it > over to lib/args.c is even possible (the semantics are close, but I'd need one > to be a strict subset of the other),
I don't know how closely the lib/args.c code is tied into the infrastructure of toybox, or if you can use it like how getopt should work by calling it directly with a struct pointer (From looking at lib/args.c, it seems like it? Although there is the GLOBALS stuff which can't easily be separated from the infrastructure) The difference between lib/args.c option strings and getopt() option strings is like the difference between ERE's and PCRE's, yes they share a common base, but the differences start to become very apparent once you move from that base. Evaluating this it seems like we could either: 1) Change lib/args.c to be a superset of getopt(3), and pry it from the GLOBALS so we can use it on it's own. Which is a large amount of effort and will only be used by 2 commands. 2) Have a -t option or something similar to it to parse toybox option strings, which still requires prying lib/args.c off the infrastructure, and likely won't be used by anything. And we still will have to pull in getopt() from libc. 3) Continue using getopt() > The existence of the -T option is a damning indictment of the entire gnu > project. As if we needed more of those. The -s option isn't doing them any > favors either: PICK ONE. But then again, this is gnu we're talking about: getopt -s should probably be like cpio -H, ignored and set to the one thing everyone uses, and kept in the option string so that we don't error and autoconf doesn't whine. ideally without using eval which is a horrible nightmare for security. the 4 options GNU lets you pick from are sh (Bourne Shell?) bash csh and tcsh. Bash is a superset of sh, and {t,}csh isn't used by anything these days from my knowledge. > Rob - Oliver Webb <aquahobby...@proton.me> _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net