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 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 nor argv 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