I've just started writing a small pet command line application. To start
things off I'm going to implement the handling of the command line options.
At first glance it seems that the best way to do it is to see the possible
arguments as some type of language and then write a small parser to handle
the passed arguments accordingly.

On the other hand, it seems to take a bit of work to do it, as it may need
quite a few FSMs. As it is a pretty frequent task, I believe that there
must be a better, easier way to do it.

So, how do you handle the command line arguments? 


Thanks in advance
Rui Maciel

"Rui Maciel" <rui.maciel@gmail.com> schrieb im Newsbeitrag 
news:4662b91a$0$27061$a729d347@news.telepac.pt...
> I've just started writing a small pet command line application. To start
> things off I'm going to implement the handling of the command line 
> options.
> At first glance it seems that the best way to do it is to see the possible
> arguments as some type of language and then write a small parser to handle
> the passed arguments accordingly.
>
> On the other hand, it seems to take a bit of work to do it, as it may need
> quite a few FSMs. As it is a pretty frequent task, I believe that there
> must be a better, easier way to do it.
>
> So, how do you handle the command line arguments?
>
>
> Thanks in advance
> Rui Maciel

Hi
I use optarg()
Its like OPTARG in a shell.
Look for it on your computer in the libs.
Regards
Reinhard 

Rui Maciel <rui.maciel@gmail.com> writes:

> I've just started writing a small pet command line application. To start
> things off I'm going to implement the handling of the command line options.
> At first glance it seems that the best way to do it is to see the possible
> arguments as some type of language and then write a small parser to handle
> the passed arguments accordingly.

It is unlikely that you need anything that sophisticated.  If your
argument syntax is that complex, then I'd be inclined to pass them off
to a lex/yacc built parser.

> On the other hand, it seems to take a bit of work to do it, as it may need
> quite a few FSMs. As it is a pretty frequent task, I believe that there
> must be a better, easier way to do it.

Your compiler/library might have something already.  You don't say
what you are using (unless that is what the [C] in your subject line
means).  Many languages have a binding to GNU's getopt and
getopt_long.  These are good for most programs and you get the
advantage of providing your users with "standard" syntax (scare quotes
because it is only standard for programs that use getopt!).

-- 
Ben.

Rui Maciel wrote:
> I've just started writing a small pet command line application. To start
> things off I'm going to implement the handling of the command line options.
> At first glance it seems that the best way to do it is to see the possible
> arguments as some type of language and then write a small parser to handle
> the passed arguments accordingly.
> 
> On the other hand, it seems to take a bit of work to do it, as it may need
> quite a few FSMs.

It depends on how complex your arguments' syntax is.  For quickie programs,
often all you need is single arguments (switches) and pairs of arguments
(an argument name and a value).  In that case, you can usually do something
like this (in pseudo-code):

	// initialize some default values here

	while (not arglist.empty()) {
	    argname = arglist.takeHead();

	    if (argname == "--debug") {
	        debugflag = true;
	    } elsif (argname == "--output-file") {
	        if (arglist.empty()) {
	            throw ArgParsingException("--output-file requires value");
	        }

	        outputFile = arglist.takeHead();
	    } else {
	        throw ArgParsingException("unrecognized argument " + argname);
	    }
	}

	// do semantic checking here -- required arguments, conflicting
	// arguments, etc.

That's dead simple and often quicker and less code than using some
argument-parsing library.  (Although you do get some things for free
with a library.)

Most commands have an argument syntax that requires just a regular grammar,
so the parsing isn't really that hard.  There are exceptions though.  For
instance, the "find" command on Unix needs a context-free grammar for its
arguments.

   - Logan

Rui Maciel wrote:
> 
> I've just started writing a small pet command line application. To
> start things off I'm going to implement the handling of the command
> line options. At first glance it seems that the best way to do it
> is to see the possible arguments as some type of language and then
> write a small parser to handle the passed arguments accordingly.

To command a pet you probably need the pet's name first.  So that
should probably be the first parameter.  You will find it in
*argv[1] as a char. string provided argc is greater than 1.

hth.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

Logan Shaw wrote:

> It depends on how complex your arguments' syntax is.  For quickie
> programs, often all you need is single arguments (switches) and pairs of
> arguments (an argument name and a value).  In that case, you can usually
> do something like this (in pseudo-code):

<snip code/>

That sounds reasonable. I'll go with it.

Thanks for the help. Kudos!


Rui Maciel