2009/7/23 Steven W. Orr <[email protected]>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/22/09 23:20, quoth Tony Nelson:
> > On 09-07-22 22:51:23, Steven W. Orr wrote:
> >
> >> Right. There's a standard for how command options should work.
> >>
> >> verb options arguments
> >>
> >> That's why we have getopt and that's why I shudder when I see people
> >> reinventing wheels.
> >
> >>From `man 3 getopt`:
> >
> >     "By  default,  getopt()  permutes  the  contents  of argv as it
> >     scans, so that eventually all the non-options are at the end."
> >
> > So, the default "standard" is to allow mixed options and arguments.
> >
>
> That's why it's so important to do it correctly. Performing consistency
> checking is also an important part of the job. For bash programming, I've
> actually been using the builtin getopts. If you're in C code, I'd recommend
> calling getopt with a + prefixing the first arg.
>
> The main point is that people should design their command lines using POSIX
> or
> SVR4 standards in the first place. Then the decision to use things like
> getopt
> or getopts gets a lot easier.
>
> Take a look at gcc as a classic example of how *not* to do it.
>
> gcc --help # I'm good with that.
> gcc -c # Also good. Let's make object code.


This is about where I am going to loose it !

>
> gcc -pipe # That's where you lose me. It's just a good thing they don't
> have a
>  -p, -i or a -e option. Or wait! Maybe they can't now.
>


Ahhhhh, I have lost it !!!!

Yeah, it really, really, ought to be '--pipe' and I like a ':' or '=' before
an attached item like a filename or option.

Aaron

P.S. All these inconsistancies are a plot designed by bad programmers to
annoy both good users and good programmers alike !
-- 
fedora-list mailing list
[email protected]
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

Reply via email to