+1 on that.
There's the secondary issue of how to pass filename/dirname arguments
to the commands. All the commands behave like CVS by default (recurse
on dirs, implied ".", and all that). So I was thinking about a series
of steps like this:
1. Parse out all the options and their arguments, put them
somewhere. Anything remaining on the command line is a direct
(non-option) argument to the command.
2. Parse out non-file/non-dir arguments (such as the property name
in a propset command, for example), put them somewhere.
3. Remaining arguments are files and dirs. Have a single function
that removes redundancies from this set (if you're recursing
into bar anyway, then mentioning bar/foo.c is pointless), and
passes it along to the command as the keys in a hash table.
The cool thing is that if the command needs to return information
about individual entities, it can do so via the same hash table,
either sticking values on the existing keys, and/or creating new
keys. The "status" command does this, for example.
-K
Greg Stein <gstein@lyra.org> writes:
> 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