Dave Glowacki wrote:
>
> Bruce Korb wrote:
> > > But seriously, I think we should (eventually if not immediately)
> > > support the more flexible GNU way, because it does result in increased
> > > convenience for the user, and is no more ambiguous than the other way.
> > > [By the way, CVS, to my surprise, requires that the command options
> > > come before command arguments.]
> >
> > That *is* according to the POSIX command line standard.
>
> Nope, it's exactly opposite the POSIX standard. CVS does
> 'cvs update -AP', POSIX says it should be 'cvs -AP update',
> (as in 'ls -lt /root').
You are right. I think I was replying to a different post
at the time. :-)
CVS requires this:
cvs [ <global-cvs-opt> ... ] \
<subcommand> [ <subcmd-opts> ...] [ <sub-cmd-arg>...]
the only options appearing before the subcommand are the options
to the `cvs' command itself. AND those particular options *must*
appear there *between* the `cvs' command and its subcommand.
SO, the options follow the command that they "modify", it is
just that there are two commands (a command and subcommand) on
the command line. We are changing this so that the global
options are parsed with the subcommand options. We are arguing
over whether or not the subcommand should appear after the subcommand
options on the command line. It is not an unsolvable problem,
but *FAR* more trouble than it is worth.
- Bruce
Received on Sat Oct 21 14:36:11 2006