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 ]
>> or
>>    zoneadm reboot -- fred [ boot-args ]
>> or
>>    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 
is concerned.

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.

- Jörg
zones-discuss mailing list

Reply via email to