pupa-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Argument parser


From: Yoshinori K. Okuji
Subject: Re: Argument parser
Date: Wed, 17 Dec 2003 10:12:49 +0100
User-agent: KMail/1.5

On Tuesday 16 December 2003 19:10, Marco Gerards wrote:
> One thing that will remain  is the structure that describes the
> arguments, this will still look like this example:
[snipped]
> I believe the parser will be easy to use this way.  It still can be
> full featured and GNU compatible (which is, as you might have
> noticed, important to me). Do you like this approach better?  If you
> can find any other problems I can fix it.  When we agree about the
> parser I will implement it.

Yes, it's very nice. One possible problem would be how to deal with 
multiple instances of the same option, like:

diff -x CVS -x '*~' foo bar

Normally, most commands assume that only the last specified option is 
significant, so it might not be necessary to worry about this problem.

> > > What do you exactly mean with the POSIX way?  Only short options?
> >
> > See the section COMPATIBILITY in the manpage of getopt(3).
>
> Ah, this section was not in the getopt manpage in the GNU/Linux
> distribution I use.

Sorry, I should have meant getopt(1). It says:

COMPATIBILITY
       This version of getopt(1) is written to be as compatible as 
possible to
       other  versions.  Usually  you  can just replace them with this 
version
       without any modifications, and with some advantages.

       If the first character of the first parameter of getopt is not  a  
`-',
       getopt goes into compatibility mode. It will interpret its first 
param-
       eter as the string of short options, and all other  arguments  
will  be
       parsed. It will still do parameter shuffling (ie. all non-option 
param-
       eters are  outputed  at  the  end),  unless  the  environment  
variable
       POSIXLY_CORRECT is set.

       The  environment variable GETOPT_COMPATIBLE forces getopt into 
compati-
       bility mode. Setting both this environment variable and 
POSIXLY_CORRECT
       offers  100%  compatibility  for `difficult' programs. Usually, 
though,
       neither is needed.

       In compatibility mode, leading `-' and  `+'  characters  in  the  
short
       options string are ignored.


Basically, POSIX mode stops parsing options as soon as encountering a 
non-option argument, while GNU does not stop. If you want more info, I 
can consult my copy of the POSIX document, or you can look at susv2 on 
the web.

Okuji




reply via email to

[Prev in Thread] Current Thread [Next in Thread]