Re: [zones-discuss] Making zoneadm more like the other adms...
Darren Reed writes: 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] You might want to review the CLIP specification and companion, as the above goal seems to be out of step -- options are supposed to go before the operand, not trailing after: http://opensolaris.org/os/community/arc/caselog/2006/062/spec-clip-html/ I'm not really a fan of CLIP, but I am a fan of consistency. To the degree we can manage it, we shouldn't have individual utilities striking out to explore new command line syntax territory. ...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. I think that misses part of the point of the compatibility feature in -u. When you supply both -u and -z, we select the zone matching based on UUID first. If there is no such zone, then we select the zone matching based on name. This allows us to deal with the upgrade cases from S10 FCS where there was no UUID. In this new world without option introducers, such a situation would require the user (or script) to supply both the UUID and the zone on the command line, making the syntax a rather confusing: zoneadm subcommand [UUID] [name] I'm still really unclear on what problem we're solving. Is it just that zlogin has a command line that behaves like rlogin (needing no option to select host), and that zoneadm/zonecfg use an option to specify the same thing? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
On Fri, Jun 20, 2008 at 09:59:31AM -0400, James Carlson wrote: Darren Reed writes: 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] You might want to review the CLIP specification and companion, as the above goal seems to be out of step -- options are supposed to go before the operand, not trailing after: http://opensolaris.org/os/community/arc/caselog/2006/062/spec-clip-html/ I'm not really a fan of CLIP, but I am a fan of consistency. To the degree we can manage it, we shouldn't have individual utilities striking out to explore new command line syntax territory. Of course, the CLIP doesn't necessarily help in that department (consistency). Witness zoneadm: CLIP compliant, yes, but rather different from all the other *adm commands. Just sayin' :) ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
James Carlson wrote: Darren Reed writes: 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] You might want to review the CLIP specification and companion, as the above goal seems to be out of step -- options are supposed to go before the operand, not trailing after: http://opensolaris.org/os/community/arc/caselog/2006/062/spec-clip-html/ I'm not really a fan of CLIP, but I am a fan of consistency. To the degree we can manage it, we shouldn't have individual utilities striking out to explore new command line syntax territory. CLIP delivered us inetadm, zoneadm and svcadm all new in Solaris 10. Given the disparity between these three new commands, I'm going to declare CLIP a failure and that we should just ignore it. I'm still really unclear on what problem we're solving. Is it just that zlogin has a command line that behaves like rlogin (needing no option to select host), and that zoneadm/zonecfg use an option to specify the same thing. The problem is the lack of consistency between *adm commands. inetadm should probably be whacked as well - if we care about it enough. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
Darren Reed wrote: Hmmm, I think I prefer the bottom one, but I can't see why either precludes the other as I'm pretty confident no sane person will ever want a zone name that matches a uuid and code could easily be written to cover this. Are zones required to have names? If so, one case where a sane person might want a zone name that matches a uuid is if they really don't care about the name - they just need another zone that doesn't conflict with any existing zones. An automated test framework might want such a thing, for instance - build a zone, run a test, tear down the zone. I've considered using uuids in a variety of places where human-readable tags are more usual, simply because uuids have no intrinsic meaning. My current project is derived from about five previous projects, and so our directory and package names are all over the map... in some ways, it's be better if we'd used uuids for all of the names. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
Jordan Brown wrote: Darren Reed wrote: Hmmm, I think I prefer the bottom one, but I can't see why either precludes the other as I'm pretty confident no sane person will ever want a zone name that matches a uuid and code could easily be written to cover this. Are zones required to have names? Unless zonecfg has a magic option to not need them, yes. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
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
Re: [zones-discuss] Making zoneadm more like the other adms...
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[1] 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. Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
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[1] 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. - Jörg ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
On Thu, Jun 19, 2008 at 06:19:30PM +0200, Joerg Barfurth wrote: Nicolas Williams schrieb: zoneadm subcommand [all-options] 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. I see. I think the zone argument shouldn't become an operand. It should remain an option argument. I realize that the FMRI argument in svcadm is an operand, not an option argument; similarly with the link argument for dladm, etc... But c'est la vie. The thing is that for *some* zoneadm commands the zonename cannot become an operand that is given last, e.g., boot; and install depends on how the brand in question works. And so on. So, IMO it's too late to make the change that Darren wants, or at least to make it consistently. Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
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[1] 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[1] nor argv[2] 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 zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
Joerg Barfurth wrote: I was away a couple of days, but still wanted to comment. Darren Reed schrieb: Something that really annoys me with zoneadm is that the syntax for its command line is different to the other new commands, ie the subommand comes after the zone name and the zone name needs to have a -z before it. ugh. So I went and looked at zoneadm.c - it seems well enough structured to make hacking easy.. 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? 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. 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. 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. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
Hey Darren, Are you interested in drafting an arc fasttrack for these interface additions? Do you see zoneadm being used as: # zoneadm boot myzone -s That would be: - myzone is an operand to zoneadm that comes after the subcommand. This is not compliant with getopt or clip guidelines. You may want to review the info here: http://opensolaris.org/os/community/arc/caselog/2006/062/spec-clip-html/ I think the usability issue is with the zoneadm syntax: # command -opt optarg subcommand ... The above clip guidlines make this comment: Q: I'd like to have options before my subcommands. This makes sense because some options apply to all operations. A: This often makes sense from an engineering perspective, but our usability data says most users don't understand the system model well enough to be able to predict whether the option should go before or after the subcommand. From this you could argue that the current zoneadm command is getopt, but not fully clip compliant. I think that you are proposing that the zonename could also take a special operand to the zoneadm command, which comes after the subcommand. The good commands that you are comparing zoneadm to were nice enough to not have any options/optargs before the subcommand. You might try running a fastrack, arguing that the syntax: # zoneadm boot myzone -m milestone=single-user being: # command subcommand operand suboptions suboperands while conforming to no standards/guidelines, is more usable than: # command option optarg subcommand suboptions suboperand. I think this could be defined as: if -z is not present, a subcommand is present, and the token after the subcommand is not an option, then it is the operand to an implicit -z. This is of course not compliant with anything. You could argue that this is more usable anyway, or you could find a compliant solution. -Steve L. On Sun, Jun 15, 2008 at 06:15:46PM -0700, Darren Reed wrote: Tony Ambrozie wrote: Your code changes for both zoneadm and zonecfg would preserve the current zonexxx -z zonename for backwards compatibility purposes, is that correct? Correct. There are some command line options that the changes I've made don't support, such as using -R. That's quite deliberate. The aim of the changes was to address the common use cases of the commands and make their use more intuitive when viewed with the other commands in OpenSolaris. Darren Thank you, On Mon, Jun 9, 2008 at 11:51 AM, Darren Reed [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Someone mentioned zonecfg was the cause of some similar awkwardness... So here's a patch attached for that. Darren --- usr/src/cmd/zonecfg/zonecfg.c --- Index: usr/src/cmd/zonecfg/zonecfg.c *** /biscuit/onnv/usr/src/cmd/zonecfg/zonecfg.c Mon Mar 24 17:30:38 2008 --- /biscuit/onnv_20080608/usr/src/cmd/zonecfg/zonecfg.c Mon Jun 9 11:47:41 2008 *** *** 1071,1076 --- 1071,1077 execname, cmd_to_str(CMD_HELP)); (void) fprintf(fp, \t%s -z zone\t\t\t(%s)\n, execname, gettext(interactive)); + (void) fprintf(fp, \t%s command zone\n, execname); (void) fprintf(fp, \t%s -z zone command\n, execname); (void) fprintf(fp, \t%s -z zone -f command-file\n, execname); *** *** 6653,6689 return (execbasename); } ! int ! main(int argc, char *argv[]) { ! int err, arg; ! struct stat st; ! ! /* This must be before anything goes to stdout. */ ! setbuf(stdout, NULL); ! ! saw_error = B_FALSE; ! cmd_file_mode = B_FALSE; ! execname = get_execbasename(argv[0]); ! ! (void) setlocale(LC_ALL, ); ! (void) textdomain(TEXT_DOMAIN); ! ! if (getzoneid() != GLOBAL_ZONEID) { ! zerr(gettext(%s can only be run from the global zone.), ! execname); ! exit(Z_ERR); ! } ! ! if (argc 2) { ! usage(B_FALSE, HELP_USAGE | HELP_SUBCMDS); exit(Z_USAGE); } ! if (strcmp(argv[1], cmd_to_str(CMD_HELP)) == 0) { ! (void) one_command_at_a_time(argc - 1, (argv[1])); ! exit(Z_OK); ! } while ((arg = getopt(argc, argv, ?f:R:z:)) != EOF) { switch (arg) { case '?': --- 6654,6679 return (execbasename); } ! static void ! set_zonename(char *zonename) {
Re: [zones-discuss] Making zoneadm more like the other adms...
Your code changes for both zoneadm and zonecfg would preserve the current zonexxx -z zonename for backwards compatibility purposes, is that correct? Thank you, On Mon, Jun 9, 2008 at 11:51 AM, Darren Reed [EMAIL PROTECTED] wrote: Someone mentioned zonecfg was the cause of some similar awkwardness... So here's a patch attached for that. Darren --- usr/src/cmd/zonecfg/zonecfg.c --- Index: usr/src/cmd/zonecfg/zonecfg.c *** /biscuit/onnv/usr/src/cmd/zonecfg/zonecfg.c Mon Mar 24 17:30:38 2008 --- /biscuit/onnv_20080608/usr/src/cmd/zonecfg/zonecfg.cMon Jun 9 11:47:41 2008 *** *** 1071,1076 --- 1071,1077 execname, cmd_to_str(CMD_HELP)); (void) fprintf(fp, \t%s -z zone\t\t\t(%s)\n, execname, gettext(interactive)); + (void) fprintf(fp, \t%s command zone\n, execname); (void) fprintf(fp, \t%s -z zone command\n, execname); (void) fprintf(fp, \t%s -z zone -f command-file\n, execname); *** *** 6653,6689 return (execbasename); } ! int ! main(int argc, char *argv[]) { ! int err, arg; ! struct stat st; ! ! /* This must be before anything goes to stdout. */ ! setbuf(stdout, NULL); ! ! saw_error = B_FALSE; ! cmd_file_mode = B_FALSE; ! execname = get_execbasename(argv[0]); ! ! (void) setlocale(LC_ALL, ); ! (void) textdomain(TEXT_DOMAIN); ! ! if (getzoneid() != GLOBAL_ZONEID) { ! zerr(gettext(%s can only be run from the global zone.), ! execname); ! exit(Z_ERR); ! } ! ! if (argc 2) { ! usage(B_FALSE, HELP_USAGE | HELP_SUBCMDS); exit(Z_USAGE); } ! if (strcmp(argv[1], cmd_to_str(CMD_HELP)) == 0) { ! (void) one_command_at_a_time(argc - 1, (argv[1])); ! exit(Z_OK); ! } while ((arg = getopt(argc, argv, ?f:R:z:)) != EOF) { switch (arg) { case '?': --- 6654,6679 return (execbasename); } ! static void ! set_zonename(char *zonename) { ! if (strcmp(zonename, GLOBAL_ZONENAME) == 0) { ! global_zone = B_TRUE; ! } else if (zonecfg_validate_zonename(zonename) != Z_OK) { ! zone_perror(zonename, Z_BOGUS_ZONE_NAME, B_TRUE); ! usage(B_FALSE, HELP_SYNTAX); exit(Z_USAGE); } ! (void) strlcpy(zone, zonename, sizeof (zone)); ! (void) strlcpy(revert_zone, zonename, sizeof (zone)); ! } + static void + get_clioptions(int argc, char *argv[]) + { + struct stat st; + int arg; + while ((arg = getopt(argc, argv, ?f:R:z:)) != EOF) { switch (arg) { case '?': *** *** 6712,6726 zonecfg_set_root(optarg); break; case 'z': ! if (strcmp(optarg, GLOBAL_ZONENAME) == 0) { ! global_zone = B_TRUE; ! } else if (zonecfg_validate_zonename(optarg) != Z_OK) { ! zone_perror(optarg, Z_BOGUS_ZONE_NAME, B_TRUE); ! usage(B_FALSE, HELP_SYNTAX); ! exit(Z_USAGE); ! } ! (void) strlcpy(zone, optarg, sizeof (zone)); ! (void) strlcpy(revert_zone, optarg, sizeof (zone)); break; default: usage(B_FALSE, HELP_USAGE); --- 6702,6708 zonecfg_set_root(optarg); break; case 'z': ! set_zonename(optarg); break; default: usage(B_FALSE, HELP_USAGE); *** *** 6727,6733 --- 6709,6761 exit(Z_USAGE); } } + } + int + main(int argc, char *argv[]) + { + int err; + + /* This must be before anything goes to stdout. */ + setbuf(stdout, NULL); + + saw_error = B_FALSE; + cmd_file_mode = B_FALSE; + execname = get_execbasename(argv[0]); + + (void) setlocale(LC_ALL, ); + (void) textdomain(TEXT_DOMAIN); + + if (getzoneid() != GLOBAL_ZONEID) { + zerr(gettext(%s can only be run from the global zone.), + execname); + exit(Z_ERR); + } + + if (argc 2) { + usage(B_FALSE, HELP_USAGE | HELP_SUBCMDS); + exit(Z_USAGE); + } + if (strcmp(argv[1], cmd_to_str(CMD_HELP)) == 0) { + (void) one_command_at_a_time(argc - 1, (argv[1])); + exit(Z_OK); + } + + if
Re: [zones-discuss] Making zoneadm more like the other adms...
Tony Ambrozie wrote: Your code changes for both zoneadm and zonecfg would preserve the current zonexxx -z zonename for backwards compatibility purposes, is that correct? Correct. There are some command line options that the changes I've made don't support, such as using -R. That's quite deliberate. The aim of the changes was to address the common use cases of the commands and make their use more intuitive when viewed with the other commands in OpenSolaris. Darren Thank you, On Mon, Jun 9, 2008 at 11:51 AM, Darren Reed [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Someone mentioned zonecfg was the cause of some similar awkwardness... So here's a patch attached for that. Darren --- usr/src/cmd/zonecfg/zonecfg.c --- Index: usr/src/cmd/zonecfg/zonecfg.c *** /biscuit/onnv/usr/src/cmd/zonecfg/zonecfg.c Mon Mar 24 17:30:38 2008 --- /biscuit/onnv_20080608/usr/src/cmd/zonecfg/zonecfg.c Mon Jun 9 11:47:41 2008 *** *** 1071,1076 --- 1071,1077 execname, cmd_to_str(CMD_HELP)); (void) fprintf(fp, \t%s -z zone\t\t\t(%s)\n, execname, gettext(interactive)); + (void) fprintf(fp, \t%s command zone\n, execname); (void) fprintf(fp, \t%s -z zone command\n, execname); (void) fprintf(fp, \t%s -z zone -f command-file\n, execname); *** *** 6653,6689 return (execbasename); } ! int ! main(int argc, char *argv[]) { ! int err, arg; ! struct stat st; ! ! /* This must be before anything goes to stdout. */ ! setbuf(stdout, NULL); ! ! saw_error = B_FALSE; ! cmd_file_mode = B_FALSE; ! execname = get_execbasename(argv[0]); ! ! (void) setlocale(LC_ALL, ); ! (void) textdomain(TEXT_DOMAIN); ! ! if (getzoneid() != GLOBAL_ZONEID) { ! zerr(gettext(%s can only be run from the global zone.), ! execname); ! exit(Z_ERR); ! } ! ! if (argc 2) { ! usage(B_FALSE, HELP_USAGE | HELP_SUBCMDS); exit(Z_USAGE); } ! if (strcmp(argv[1], cmd_to_str(CMD_HELP)) == 0) { ! (void) one_command_at_a_time(argc - 1, (argv[1])); ! exit(Z_OK); ! } while ((arg = getopt(argc, argv, ?f:R:z:)) != EOF) { switch (arg) { case '?': --- 6654,6679 return (execbasename); } ! static void ! set_zonename(char *zonename) { ! if (strcmp(zonename, GLOBAL_ZONENAME) == 0) { ! global_zone = B_TRUE; ! } else if (zonecfg_validate_zonename(zonename) != Z_OK) { ! zone_perror(zonename, Z_BOGUS_ZONE_NAME, B_TRUE); ! usage(B_FALSE, HELP_SYNTAX); exit(Z_USAGE); } ! (void) strlcpy(zone, zonename, sizeof (zone)); ! (void) strlcpy(revert_zone, zonename, sizeof (zone)); ! } + static void + get_clioptions(int argc, char *argv[]) + { + struct stat st; + int arg; + while ((arg = getopt(argc, argv, ?f:R:z:)) != EOF) { switch (arg) { case '?': *** *** 6712,6726 zonecfg_set_root(optarg); break; case 'z': ! if (strcmp(optarg, GLOBAL_ZONENAME) == 0) { ! global_zone = B_TRUE; ! } else if (zonecfg_validate_zonename(optarg) != Z_OK) { ! zone_perror(optarg, Z_BOGUS_ZONE_NAME, B_TRUE); ! usage(B_FALSE, HELP_SYNTAX); ! exit(Z_USAGE); ! } ! (void) strlcpy(zone, optarg, sizeof (zone)); ! (void) strlcpy(revert_zone, optarg, sizeof (zone)); break; default: usage(B_FALSE, HELP_USAGE); --- 6702,6708 zonecfg_set_root(optarg); break; case 'z': ! set_zonename(optarg); break; default: usage(B_FALSE, HELP_USAGE); *** *** 6727,6733 --- 6709,6761 exit(Z_USAGE); } } + } + int