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 require
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
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
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
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 a
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
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
>>>
>>> zon
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
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 i
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
>
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
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 u
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 guide
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
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
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 quit
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 awkwa
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_2008
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
19 matches
Mail list logo
