Ilja Booij <[EMAIL PROTECTED]> said: > Matthew T. O'Connor wrote: > >On Wed, 2004-07-07 at 08:15, Ilja Booij wrote: > >>This looks ok. I don't think we should go for the non-standard long > >>options (although I know for experience that they're > >>very useful). > >> > >They are very useful, and far more user friendly I think. Why do you > >think we shouldn't use them? > > > Hmm, I thoought they did not exits on non-GNU systems. However, I found > getopt_long on Mac OS X. > > Is there anybody one *BSD that can check whether or not getopt_long is > present there?
Whether it is present or not, I have a public domain version that I've used before on Solaris and it works very nicely. We can let autoconf decide whether to use the system's getopt_long or our own. However, I'm not suggesting using getopt_long for the main modes; rather, I'm suggesting that after looping argv through getopt, looking at the first non-switch argument and taking it to be a plain text keyword. Much like: cvs commit -m "message" ... mysqladmin flushprivs ... I've always thought it was a little odd to use the same argument style for options as well as mutually-exclusive, required operating modes. Like tar: tar -txc gives you a cryptic error about how you have to pick one of -t, -x or -c (and I think that there might be a few more of those, but you get the picture. I'm thinking that this would be more sensical a model to follow, and by using getopt, we allow those switches to be in any position. What's important is that the first non-switch is the mode and the second non-switch is the username/list of aliases/whatever primary argument is required. tar extract -vf filename.tgz Aaron --
