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 zones-discuss@opensolaris.org
