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

[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...

[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...

[Darren Reed]

James Carlson wrote:

>Darren Reed writes:
>  
>
>>2) it would seem the next place worth going is:
>>  zoneadm  [all options]
>>
>>3) but what I'd rather do is:
>>  zoneadm   [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  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  [] []
>  
>

So the command line would look like:

zoneadm boot d66e28e2-d1d4-6a3d-febe-e76e5af17812 fred

or

zoneadm boot fred d66e28e2-d1d4-6a3d-febe-e76e5af17812

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.

Darren

___
zones-discuss mailing list
zones-discuss@opensolaris.org

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

[Darren Reed]

James Carlson wrote:

>Darren Reed writes:
>  
>
>>2) it would seem the next place worth going is:
>>  zoneadm  [all options]
>>
>>3) but what I'd rather do is:
>>  zoneadm   [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...

[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  [all options]
> > 
> > 3) but what I'd rather do is:
> >   zoneadm   [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]

Darren Reed writes:
> 2) it would seem the next place worth going is:
>   zoneadm  [all options]
> 
> 3) but what I'd rather do is:
>   zoneadm   [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  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  [] []

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...

[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  [] [ []]
>>>
>>> and that this is more usable than the current
>>>
>>> zoneadm []  [] []
>>
>>
>> Given that the  and  today don't conflict, why
>> not just:
>>
>> zoneadm  []
>>
>> 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   [sub-options]

2) it would seem the next place worth going is:
  zoneadm  [all options]

3) but what I'd rather do is:
  zoneadm   [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  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 "" 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...

[Nicolas Williams]

On Thu, Jun 19, 2008 at 06:19:30PM +0200, Joerg Barfurth wrote:
> Nicolas Williams schrieb:
> >zoneadm  []
> 
> 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]

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  [] [ []]
>>
>> and that this is more usable than the current
>>
>> zoneadm []  [] []
> 
> Given that the  and  today don't conflict, why
> not just:
> 
> zoneadm  []
> 
> 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...

[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  [] [ []]
> 
> and that this is more usable than the current
> 
> zoneadm []  [] []

Given that the  and  today don't conflict, why
not just:

zoneadm  []

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...

[James Carlson]

Joerg Barfurth writes:
> 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.

Besides being a Committed interface (which would require some
attention to compatibility), there are also scripts inside LU that are
dependent on that syntax, others in some management applications (such
as those used by TX)), as well as other externally-designed scripts
that use it.

I think that supporting the old syntax is a minimum requirement, which
(in addition to other problems) means you likely end up having have to
define what "zoneadm -z foo boot bar" actually means.

-- 
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...

[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  [] [ []]

and that this is more usable than the current

zoneadm []  [] []

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...

[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] 
> > > 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 \t\t\t(%s)\n",
> >execname, gettext("interactive"));
> > +   (void) fprintf(fp, "\t%s  \n",
> > execname);
> >(void) fprintf(fp, "\t%s -z  \n",
> > execname);
> >(void) fprintf(fp, "\t%s -z  -f
> > \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) {
> >c

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

[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...

[Joerg Barfurth]

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. 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

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?

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


> At present my ability to test seems to be being challenged
> by networks problems/outages here at Sun, so please forgive
> me if there are some bugs (obvious or otherwise.)
> 

One obvious bug with the change is that the new setroot function doesn't 
use its 'arg' argument, but instead operates directly on the global optarg.

- Jörg

-- 
Joerg Barfurth   phone: +49 40 23646662 / x2
Software Engineermailto:[EMAIL PROTECTED]
Desktop Technology   http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software http://www.sun.com/software/sunray/
Sun Microsystems GmbHhttp://www.sun.com/software/javadesktopsystem/


___
zones-discuss mailing list
zones-discuss@opensolaris.org

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

[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] 
> > 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 \t\t\t(%s)\n",
>execname, gettext("interactive"));
> +   (void) fprintf(fp, "\t%s  \n",
> execname);
>(void) fprintf(fp, "\t%s -z  \n",
> execname);
>(void) fprintf(fp, "\t%s -z  -f
> \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 
> --- 

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

[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 \t\t\t(%s)\n",
>execname, gettext("interactive"));
> +   (void) fprintf(fp, "\t%s  \n", execname);
>(void) fprintf(fp, "\t%s -z  \n", execname);
>(void) fprintf(fp, "\t%s -z  -f \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))

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

[Darren Reed]

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 \t\t\t(%s)\n",
execname, gettext("interactive"));
+   (void) fprintf(fp, "\t%s  \n", execname);
(void) fprintf(fp, "\t%s -z  \n", execname);
(void) fprintf(fp, "\t%s -z  -f \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 (argc >= 3 && *argv[1] != '-' && *argv[2] != '-') {
+   /*
+* We're assuming that the command line has been written
+* as "zonecfg subcmd zonename" but the parser for the CLI
+* assumes "zonecfg -z zone subcmd".  If we move the
+* subcommand and adjust optind, we