Karl Fogel wrote:
>
> Thank you. :-)
Oh, you're welcome ;-)
> > The following needed to be prose anyway:
> >
> > there needs to be a semantic constraint on the syntax
> > of the ``svn [<sub-cmd>] [<opt> ...] [<arg> ...]''.
> > It is probably "obvious", but if the first argument
> > to the svn command starts with a hyphen, then all the
> > arguments to svn must be options from the set of common
> > options. i.e.:
> >
> > svn <sub-cmd> [<sub-cmd-opt> ...] [<arg> ...]
> > svn [ <common-opt> ... ]
> >
> > are the two forms.
>
> I'm not sure I understand what you mean.
Maybe my meaning would be clearer if ``<common-opt>''
were constrained to the single option ``--help''?
Again, I am thinking about decidability. What would you
do with the <arg>... list if no subcommand were specified?
Or with the options themselves, if they were subcommand specific?
The invocation:
svn update ...
starts with a subcommand, not an argument with an option
marker (aka hyphen).
> > In keeping with `svn' being a shell, I also propose
> > exit | quit
> > help
> The shell is for the future, not 1.0. I wouldn't spend too much
> mental energy on it, as we're unlikely to take the client in a
> direction that is not compatible with shell-like operation later.
This was not very much mental energy. :-)
Received on Sat Oct 21 14:36:12 2006