> Ahh, but currently the argument checking is done before the
> command and in the command.
>
> For example, take a look at propget:
<snip>
> This half and half approach is what bothers me.
> I figured that we could just add elements to
> the command table so that TARGETS parsing
> could check for the number of args just
> like the subcommand->num_args check.
> Would it be better to simply pass the
> apr_getopt_t to the command and let
> it deal with separating the initial
> arguments from the target arguments?
My initial thought was "goodness no!" but upon further reading, I
changed my mind (see below).
> Also, what about options that might
> be passed in by the user? The current
> code does not seem to deal with that.
>
> For example, with CVS you can do:
>
> cvs diff -10 file.c
>
> To pass the -10 argument through to
> the diff command. It seems like
> command line flags like this
> are going to be needed, so we
> should really deal with them
> now instead of later. A simple
> rule might be to gather up
> options (they start with -)
> and then start parsing things
> like the PROPNAME from propget
> followed by TARGET args.
Urk... that's a *really* good point. It's obvious that we need to
rethink this argument processing... I'm going to take a step back and
try and formulate (in English) exactly what we need to handle/provide
here, and then try and code from there. I'm thinking that a more
holistic approach is required here (one approach that takes into
account all the cases) instead of a bunch of different techniques.
-Fitz
Received on Sat Oct 21 14:36:25 2006