"Jonathan S. Shapiro" wrote:
>
> > Good. It should also, then, be okay to require that all
> > options appear after the subcommand name. Viz.:
> >
> > svn <subcommand> [ <option> ... ] [ <arg> ...]
> >
> > Yes?
>
> NO. There is an existing standard command processing interface. It is called
> getopts(). It specifically (and by design) does *not* require that options
> appear before arguments.
>
> The existing standard may be stupid, but it is widely well understood and it
> isn't ugly. Unless there is a really *really* compelling reason to discard
> it, don't do so.
>
> It took fifteen bloody years to *regularize* the UNIX command interface!
That leaves you with a rather interesting dilemma:
svn -x foo bar
Which is the subcommand, "foo" or "bar"?
Well, it depends. For the "foo" subcommand, -x happens to
require an argument, but for the "bar" subcommand, it does
not. Or, was that the other way around? In any event,
without knowing which is the subcommand, you cannot know
how to handle the -x flag option. Unless, of course, all
options apply to all subcommands and the subcommand processing
code has to figure out what happened. To this, *I* say, "No." :-)
Way too hard. ``svn'' + ``<subcommand>'' is the command.
Or, rather, ``<subcommand>'' is the command within the svn's
command name space, if you like.
- Bruce
Received on Sat Oct 21 14:36:11 2006