> > > So it seems that if we want to be portable, we stay with plain getopt(),
> > > steal getopt.c and .h from glibc, or use popt. Of course, how portable
> > > popt is, I have no idea yet, as I haven't been able to download it...
> > Phil, am I right that if we need to, on platforms without a native
> > getopt_long, we just leave out the last two argument to getopt_long, and
> > then call getopt(). Everything else is identical, isn't it?
> I think so. As long as we're careful, I reckon this approach would work.
Personally, I like long options so I am in favor of this. If we need to
support a system without long opts we just have
getops_long(...,last two, arguments);
> > The other solutions would be (1) use popt, or (2) put getopt.c and
> > getopt.h into the package. Blech.
> I hadn't heard of popt until today, so I can't comment on (1). (2) sounds
Of course if you like popt that might also be a portable option, but I
would prefer to limit the number of external libraries we need. It's
always a nuisance to keep up to date with the changes.
> Actually, I'm not strongly opposed to sticking with getopt(). We
> could probably make things a little simpler (and less terse) by
> replacing groups of short options with single options that take
> arguments. This would be similar to what you've done with some of the
> long options you've suggested. For example, we could replace:
> with something like:
> [-t TEST]
> where TEST takes the values offline, shortself, shortself_captive, longself,
> longself_captive, and abort.
> If we can't use long options on all platforms then I think I'd rather we opt
> for consistency (sorry, bad pun!) and use only short options.
Hmmm, I am still in favor of having both. If someone does a port to a
platform where there are no long options, we can provide a -D flag for
them to set.
But this does stress that the short options should be done carefully,
since they might be all that one has.
Anyway, I'll wait for your proposed set of short options...