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. Darren _______________________________________________ zones-discuss mailing list email@example.com