Darren Reed schrieb:
>> The attached diffs modify zoneadm to work like this:
>>> zoneadm boot fred
>> But your change becomes counterintuitive (IMHO), when subcommand
>> options are used. The result certainly doesn't fit any commandline
>> standard (CLIP, etc) I know.
> Compare the usage of zoneadm with svcadm, dladm, zfs or
> any of the other newer *adm commands that have a subcommand
> directly after the command name.
> Furthermore, I'm not concerned with any _official_ standard,
> we seem to be making up our own "standards" as we go.
> I think having all of our commands that have subcommands be
> consistent in use within the same operating system is of value,
> don't you?
Yes it is. And afaik CLIP is the consistency standard that is expected
by the ARCs for all newly designed command line syntaxes. The ...adm
commands you list all are CLIP compliant.
>> The distinction between operands and arguments get blurred when they
>> are positioned in arbitrary places. Typical syntax for command with
>> subcommands and arguments, would be
>> zoneadm detach -n fred
>> rather than
>> zoneadm detach fred -n
> This wasn't a focus of what I was doing...
> But in all seriousness, if the subcommand is going to
> follow the command name then the other important
> change is to have the key be at the end.
Do you mean that you agree that the first version is better? Your
proposed patch doesn't do that, so would need more work to behave properly.
>> OTOH a change that puts the zonename at the end is less obvious to do
>> in the code and results in less obvious syntax for subcommands that
>> have argument lists of their own, for example reboot:
>> zoneadm reboot fred [ boot-args ]
>> zoneadm reboot -- fred [ boot-args ]
>> zoneadm reboot fred [-- boot-args ]
>> Whichof those is best/acceptable/misleading?
> Considering that I do:
> reboot -- net - install
> it would seem that the best is the last.
From a purely options-parsing POV the extra -- in the last version is
unnecessary whereas it is necessary with reboot. OTOH it might be useful
for visual familiarity, so maybe it could be allowed but optional.
>> And the interaction with global options also is non-obvious. Why do
>> you support
>> zoneadm mark fred incomplete
>> (N.B: not 'zoneadm mark incomplete fred')
>> but not
>> zoneadm -R /someroot mark fred incomplete
> Because doing that was going to take longer than the short period
> of time I set aside to experiment with this - in this case, parsing the
> -R needs to be moved to be after the subcommand.
Your mail seemed to propose a syntax change by showing a changed
implementation. It wasn't clear how prototypey or unfinished the
proposal was, in particular as far as the actual syntax change proposal
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>]
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.
zones-discuss mailing list