Nicolas Williams schrieb:
> On Thu, Jun 19, 2008 at 09:36:15AM +0200, Joerg Barfurth wrote:
>> Take all the unstated (in the original post) syntax changes into 
>> account, I agree that it seems possible to have a (CLIP compliant) 
>> syntax of the form
>> zoneadm <subcommand> [<all-options>] [<zonename> [<operands>]]
>> and that this is more usable than the current
>> zoneadm [<global-opts>] <subcommand> [<subcmd-opts>] [<operands>]
> Given that the <global-opts> and <subcmd-opts> today don't conflict, why
> not just:
> zoneadm <subcommand> [<all-options>]
> where the zone on which a sub-command must operate is named with -z/-u
> as usual, just after the sub-command name?
>> Still there are some details in the required options and operands (like 
>> use of -u instead of -z or the reboot boot-options arguments) that make 
>> it tricky to do this cleanly - particularly if the old syntax needs to 
>> be kept alive for compatibility.
> The old syntax must remain, yes, for backwards compat.
> But I don't see why this is complicated.  If argv[1] doesn't start with
> - then you do the new thing and use a getopts string with all the
> options for that sub-command and all the global ones too.  Otherwise do
> as today.

That surely is a much easier change - and easy to do compatibly, if you 
allow global options both before and after the subcommand.

But Darren apparently much prefers not having to use an 'extraneous' 
option letter to designate the main object of the command (which is the 
zone). It is the attempt to morph this from option argument to operand 
that makes this complicated.

- J├Ârg
zones-discuss mailing list

Reply via email to