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? :-)
Received on Sat Oct 21 14:36:14 2006