Joerg Barfurth wrote:

> 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.

First, as has been mentioned elsewhere, various other *adm commands
do not require a option identifier ("-*") before the key, which in this case
is predicted to come after the subcommand.

Where I started from was:
1) if neither argv[1] nor argv[2] start with '-' then it is:
  zoneadm <subcommand> <zonename> [sub-options]

2) it would seem the next place worth going is:
  zoneadm <subcommand> [all options]

3) but what I'd rather do is:
  zoneadm <subcommand> <zonename> [all-options-except -z]

...but just maybe that requires (2) to allow for -u.  The other
thing to say is that any string that is going to be successfully
parsed by linuuid(3) is not going to be a normal zonename,
therefore no -u is required for <zonename> to indicate that
it is a uuid instead - the string can be passed to libuuid(3)
and if it works, we move along.  The only problem that poses
if someone was expecting "zoneadm blah uuid" to fail on
purpose - but I'd wager that more people would like it to
"just work" than fail.

Actually the only thing that is substantially different is that I
haven't supported the "<global-opts>" on the right hand side.

But the only global option of significance is -R, so that isn't
an insurmountable problem.


zones-discuss mailing list

Reply via email to