Re: [zones-discuss] Making zoneadm more like the other adms...

2008-06-20 Thread James Carlson
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...

2008-06-20 Thread Nicolas Williams
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...

2008-06-20 Thread Darren Reed
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...

2008-06-20 Thread Jordan Brown
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...

2008-06-20 Thread Darren Reed
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...

2008-06-19 Thread Joerg Barfurth
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...

2008-06-19 Thread Nicolas Williams
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...

2008-06-19 Thread Joerg Barfurth
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...

2008-06-19 Thread Nicolas Williams
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...

2008-06-19 Thread Darren Reed
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...

2008-06-18 Thread Darren Reed
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...

2008-06-18 Thread Steve Lawrence
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...

2008-06-15 Thread Tony Ambrozie
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...

2008-06-15 Thread Darren Reed
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