So while I'm running around with a machete breaking things, I'd like to do the same with our command-line args and parsing. Short version: I'm gonna rewrite it to use getopt_long(), assume the system provides it, and we'll deal with hacking around systems that don't if and when we run across them. That means our -long args will turn into --long args. That cool with everybody?
Long version: Right now, arg parsing is being patched together ad-hoc via a not entirely unfrightening pile of hand parsing. Which is why, for instance, we have a -version, and a -verbose, but -v is also verbose, as is -vanyotherdamnthingyouwannatype. Simliar things show up in a couple other args, it doesn't handle bundling, etc. All our long args are single dash (which is why we have those weird disambiguation issues), except the recently-added --replace. Also, ugly and scary. getopt(3) can be pretty well assumed to be everywhere, since A&T and Berkeley picked it up in the early-mid 80's. But it doesn't do long args, and I don't wanna drop that. getopt_long(3) should handle everything. But that's not quite as portable. Is it portable enough? On GNU libc, it goes back at least as far as 2.0 (1997), which is as far back as GNU has tarballs I can readily find, so we can assume anything Linux (unless it's running a 1.x kernel, maybe) is covered. NetBSD grew it in 1.5 (2000), FreeBSD in 5 and OpenBSD in 3.3 or possibly before (2003). There does (did?) exist a libgnugetopt that could be used on prior versions if necessary (and probably is installed on any of those vintage systems still running and getting new software put on them anyway). Solaris 9 (2002/3) doesn't have it, but there are libgnugetopt packages out there for it as well. 10+ (2005) does, and so the OpenSolaris and Illumos and such descendants would too. Darwin has had it since at least 7 (2003, OS X 10.3 Panther); couldn't trivially find earlier docs to check one way or another. Not very intensive searching didn't give me an answer for HP-UX or AIX. I'm pretty sure that covers the whole hump, and pretty near all of the tail, of the usage curve we'd possibly be worrying about for newer versions. So I propose rewriting the option parsing to use it, and just assume the system provides it. If we run across some that don't, we can add additional checks (up to and including just shipping our own copy to be used in those special cases), but I'd suggest not worrying about that unless/until it comes up. >From the user side, this would mean that the single-dash long options would go away and turn into double-dash. I would probably put in some stub manual handling so a few of them would be accepted as the first argument only (e.g., -version and -info which would pretty much only ever exist as sole args, -cfgchk and -display; those seem the most likely to be used) for a release or two to provide a little transition and make it easier to support before/after with the same set of scripts. My guess would be that, in practice, this is probably pretty near a no-op for most users, as almost every option I think gets much use in practice is probably one of the single-letter args anyway (-f alone is probably the 95th percentile or something). -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
