I'd suggest passing the options information to the command in a hash table.
The command can simply do something like apr_hash_get(hash, "v") to get the
information.
Throw in a bit of default value handling, long/short option handling, and
you're set. The apr_hash_t would create an excellent division between option
processing and option consumption.
The second part would be determining what is possible for a given command
and providing errors/warnings for options that don't match up properly.
Cheers,
-g
On Tue, Nov 14, 2000 at 03:45:43PM -0600, Karl Fogel wrote:
> Actually (I apologize if I'm just being dense, here) I'm not sure I
> understand the proposal completely..
>
> I like the idea that only main() has to parse the options, and then
> passes along the information postparsed to the subcommand, especially
> given that so many options have a common meaning across subcommands.
>
> However, I don't understand the mechanism by which this is happening;
> specifically, the mechanism by which main() passes the information
> along. It sounds like it's at least partially genericized, but what
> about option/arg combinations that are specific to a given
> subcommand. How are those passed? Are we going to make the
> subcommand procedure type variadic?
>
> As an experiment, could you try writing the log entry in advance and
> posting it? Obviously, it doesn't have to be 100% the same as what
> you actually end up doing, but knowing how the data structures are
> going to change would probably clear up these things, for me and
> (maybe) for others.
>
> -K
>
> Bruce Korb <bkorb@sco.COM> writes:
> > In preparation for ultimately doing some sort of
> > table thingey for options, I want to lay some ground work
> > now. To do this, I want to make a struct type that
> > contains all the data currently used in the client
> > options, plus the command enumeration type. Each
> > command table entry would have a pointer to a struct
> > of this type with just the command enumeration filled
> > in. The current option processing code would be called
> > from main() instead of the command procedures. The command
> > procedures would receive only command arguments (the
> > options stripped off). With this done, changing the
> > underlying option processing should no longer perterb
> > much of any other code (especially the command implementation
> > procedures.)
> >
> > I'll stick a slight rewording of this email
> > into the CVS log when I do this, ok? :-)
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:14 2006