From Sebastien.Roy@sun.com Wed Jun 11 19:35:02 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C2Z1sk018904 for ; Wed, 11 Jun 2008 19:35:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5C2YwLV006114 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 10:35:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00C03WIAZI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 19:34:58 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B008VWWIAE730@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 19:34:58 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5C2Ywdq028687 for ; Thu, 12 Jun 2008 02:34:58 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00401WA8Z300@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 20:34:58 -0600 (MDT) Received: from [192.168.1.5] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B004OWWI9VJ90@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 20:34:57 -0600 (MDT) Date: Wed, 11 Jun 2008 22:34:56 -0400 From: Sebastien Roy Subject: PSARC 2008/374 dladm parseable output Sender: Sebastien.Roy@sun.com To: psarc-ext Cc: John Leser , Peter Memishian Message-id: <1213238096.5625.33.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3858 I'm submitting this fasttrack for John Leser and Peter Memishian. The timer is set for June 18th, 2008. Overview ======== This case proposes to revise the parseable output format for dladm(1M) to be both robust and easy to parse. It also proposes a set of guidelines that we anticipate future networking CLIs will follow (and, where appropriate and feasible, could be applied to existing CLIs). Stability level is Committed. Release Binding is Minor. Background ========== In general, it's helpful for building administrative scripts as well as test cases that there be some way to cause commands to issue output in a format that is stable and easy for scripts to parse. While dladm(1M) currently provides a parseable output mode, it is not that easy to parse, especially from a shell: # dladm show-link -p LINK="e1000g0" CLASS="phys" MTU="1500" STATE="up" OVER="" LINK="e1000g1" CLASS="phys" MTU="1500" STATE="unknown" OVER="" LINK="e1000g2" CLASS="phys" MTU="1500" STATE="unknown" OVER="" LINK="e1000g3" CLASS="phys" MTU="1500" STATE="unknown" OVER="" Although one might think that "eval" could be used in the shell to access the set of values one line at a time, this has major pitfalls: * Each eval runs the risk possibly clobbering variables already in use by the script. This means that any time a new field is added, there is small but very real potential to break any script that happened to use that field name as a local variable. * Use of eval presents a significant security risk: any command where a non-privileged user might gain control over any field's value makes eval as root (say, in an admin script) unsafe. Proposal ======== We propose that parseable output employ a simple field separator scheme similar to what is already used by "zoneadm list -p": $ zoneadm list -p 0:global:running:/::native:shared However, given that ":" is common in MAC and IPv6 addresses, we propose to use "|" as the field separator. Also of note: * Since it's possible that a field value could contain a literal "|", parseable output will escape literal "|" as "\|", and literal "\" as "\\". As it happens, this escape format is already handled automatically by the "read" and "while read" shell constructs, ensuring that parsing remains simple. * Fields with no value will be shown as being empty (see the example below), rather than "-" or "--", as might be used in normal output. * As before, headers will be omitted in parseable output mode. Further, we propose that the existing "-o" switch (which is used to enumerate fields to display) be required in parseable output mode. This ensure that we will be able to add new fields in the future without potentially breaking existing scripts. Output format examples: # dladm show-link -o link,over,state LINK OVER STATE e1000g0 -- up e1000g1 -- unknown e1000g2 -- unknown e1000g3 -- unknown # dladm show-link -p dladm: output field list (-o) required in parsable output mode # dladm show-link -p -o link,over,state e1000g0||up e1000g1||unknown e1000g2||unknown e1000g3||unknown Note that this is a change to a Committed interface, but it is a relatively safe change. The Solaris 10 parseable output format was not usable and was already modified in Nevada build 83 to the format described in the Background section. Changing the format again doesn't break anything new, and the project team is aware of the existing consumers of this format since they needed to be altered in build 83. From Darren.Reed@Sun.COM Wed Jun 11 20:09:55 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C39tvF019918 for ; Wed, 11 Jun 2008 20:09:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5C39t3X025539 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 20:09:55 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00E01Y4JUZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 20:09:55 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B0080WY4IEB60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 20:09:55 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5C3AHkM012790 for ; Thu, 12 Jun 2008 03:10:17 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K2B00M01XUW9G00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 11:08:12 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K2B00FREY1MQY78@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 11:08:12 +0800 (SGT) Date: Wed, 11 Jun 2008 20:09:50 -0700 From: Darren Reed Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <1213238096.5625.33.camel@seb> Sender: Darren.Reed@Sun.COM To: Sebastien Roy Cc: psarc-ext , John Leser , Peter Memishian Message-id: <4850937E.2040504@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1626 Sebastien Roy wrote: >... > I agree with the overview and background but... > Proposal > ======== > > We propose that parseable output employ a simple field separator scheme > similar to what is already used by "zoneadm list -p": > > $ zoneadm list -p > 0:global:running:/::native:shared >... > > # dladm show-link -p -o link,over,state > e1000g0||up > e1000g1||unknown > e1000g2||unknown > e1000g3||unknown > IMHO, the output of both commands here is unusable. But given this case is not about zoneadm, lets leave that alone... Please explain why using a whitespace character such as tab as the delimiter is unworkable. My definition of parsable input means I can write a script like this in sh: dladm -o state,over | while read a b; do echo "a=$a,b=$b" done The output suggested by this case does not work nearly as easily as this and what's more the stated target of this change is shell use. It would seem to me that "dladm show-link -o link,over" is far easier to parse, with a shell, than with the additional -p. Can we please have some convergance on what is considered "parsable output" by the commands we provide in OpenSolaris and not something different for each. If that means derailing this case so that someone can write an opinion that decides what is and is not parsable, then that is what I'd like to request. I'll point out here that there are various plain text formats, using either commas or tabs to separate fields with databases and spreadsheets, that how to deal with awkward data is not considered to be a problem. Darren From peter.memishian@sun.com Wed Jun 11 20:26:10 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C3QAxp020096 for ; Wed, 11 Jun 2008 20:26:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5C3Q8qk028210 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 20:26:10 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00K03YVLGR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 21:26:09 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00MDYYVLXFA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 21:26:09 -0600 (MDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5C3Q6cA054666; Wed, 11 Jun 2008 23:26:06 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5C3Q6IC740275; Wed, 11 Jun 2008 23:26:06 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5C3Q5P9740255; Wed, 11 Jun 2008 23:26:05 -0400 (EDT) Date: Wed, 11 Jun 2008 23:26:05 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4850937E.2040504@Sun.COM> To: Darren Reed Cc: Sebastien Roy , psarc-ext , John Leser , Peter Memishian Reply-to: peter.memishian@sun.com Message-id: <18512.38733.448019.247611@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 431 > Please explain why using a whitespace character such as tab as the > delimiter is unworkable. Because most shells will consolidate multiple consecutive whitespace fields into a single field. Blank fields become unworkable. > My definition of parsable input means I can write a script like > this in sh: > > dladm -o state,over | while read a b; do > echo "a=$a,b=$b" > done That works, just set IFS=| -- meem From Darren.Reed@sun.com Wed Jun 11 20:56:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C3uPbP020653 for ; Wed, 11 Jun 2008 20:56:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5C3uI8b022191 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 04:56:24 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00H090A0BU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 20:56:24 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C0020Z09ZQK50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 20:56:24 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5C3uk82015975 for ; Thu, 12 Jun 2008 03:56:46 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K2C00C010351G00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 11:54:41 +0800 (SGT) Received: from [129.146.107.76] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K2C00FA5073R107@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 11:54:41 +0800 (SGT) Date: Wed, 11 Jun 2008 20:56:17 -0700 From: Darren Reed Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18512.38733.448019.247611@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: Peter.Memishian@sun.com Cc: Sebastien Roy , psarc-ext , John Leser Message-id: <48509E61.1010500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) Status: RO Content-Length: 613 Peter Memishian wrote: > > Please explain why using a whitespace character such as tab as the > > delimiter is unworkable. > > Because most shells will consolidate multiple consecutive whitespace > fields into a single field. Blank fields become unworkable. > > > My definition of parsable input means I can write a script like > > this in sh: > > > > dladm -o state,over | while read a b; do > > echo "a=$a,b=$b" > > done > > That works, just set IFS=| > Yes, and maybe you'd like to provide a complete example so that it can be compared with the simplicity of what I presented above. Darren From scott.rotondo@sun.com Wed Jun 11 21:39:49 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C4dnOO021613 for ; Wed, 11 Jun 2008 21:39:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5C4dfeb013396; Thu, 12 Jun 2008 12:39:46 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C003032A7EB00@brm-avmta-1.central.sun.com>; Wed, 11 Jun 2008 22:39:43 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00MEQ2A6XAC0@brm-avmta-1.central.sun.com>; Wed, 11 Jun 2008 22:39:42 -0600 (MDT) Received: from viaggio.local (punchin-rotondo.SFBay.Sun.COM [10.7.251.213]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5C4dfiA357048; Wed, 11 Jun 2008 21:39:41 -0700 (PDT) Date: Wed, 11 Jun 2008 21:41:09 -0700 From: Scott Rotondo Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48509E61.1010500@Sun.COM> To: Darren Reed Cc: Peter.Memishian@sun.com, Sebastien Roy , psarc-ext , John Leser Message-id: <4850A8E5.5050001@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 945 Darren Reed wrote: > Peter Memishian wrote: >> > Please explain why using a whitespace character such as tab as the >> > delimiter is unworkable. >> >> Because most shells will consolidate multiple consecutive whitespace >> fields into a single field. Blank fields become unworkable. >> >> > My definition of parsable input means I can write a script like >> > this in sh: >> > > dladm -o state,over | while read a b; do >> > echo "a=$a,b=$b" >> > done >> >> That works, just set IFS=| >> > > Yes, and maybe you'd like to provide a complete example so that > it can be compared with the simplicity of what I presented above. > > Darren > Having to set IFS=| may make the example marginally more complex, but it's unavoidable. A whitespace delimiter simply doesn't allow you to deal with blank fields, and doing so is a key requirement. I applaud your desire to make things as simple as possible, but not simpler. Scott From peter.memishian@sun.com Wed Jun 11 22:15:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C5F73s023008 for ; Wed, 11 Jun 2008 22:15:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5C5F7j1015990 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 22:15:07 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C003053X5CW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 22:15:05 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C002JD3X4QK80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 22:15:05 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5C5F1hB016968; Thu, 12 Jun 2008 01:15:01 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5C5F1RW775556; Thu, 12 Jun 2008 01:15:01 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5C5F1KX775553; Thu, 12 Jun 2008 01:15:01 -0400 (EDT) Date: Thu, 12 Jun 2008 01:15:01 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48509E61.1010500@Sun.COM> To: Darren Reed Cc: peter.memishian@sun.com, Sebastien Roy , psarc-ext , John Leser Reply-to: peter.memishian@sun.com Message-id: <18512.45269.518979.218519@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 564 > > > My definition of parsable input means I can write a script like > > > this in sh: > > > > > > dladm -o state,over | while read a b; do > > > echo "a=$a,b=$b" > > > done > > > > That works, just set IFS=| > > Yes, and maybe you'd like to provide a complete example so that > it can be compared with the simplicity of what I presented above. Here's your example, with the missing show-link subcommand and parsable option flag added: dladm show-link -o state,over -p | while IFS='|' read a b; do echo "a=$a,b=$b" done -- meem From Nicolas.Williams@Sun.COM Thu Jun 12 00:28:31 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C7SVYt026918 for ; Thu, 12 Jun 2008 00:28:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5C7SQGO005018; Thu, 12 Jun 2008 08:28:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00I0FA3ESV00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 00:28:26 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C002BCA3DQBF0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 00:28:26 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5C7SPU9013498; Thu, 12 Jun 2008 02:28:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5C7SPBv013497; Thu, 12 Jun 2008 02:28:25 -0500 (CDT) Date: Thu, 12 Jun 2008 02:28:25 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <1213238096.5625.33.camel@seb> To: Sebastien Roy Cc: psarc-ext , John Leser , Peter Memishian Mail-followup-to: Sebastien Roy , psarc-ext , John Leser , Peter Memishian Message-id: <20080612072824.GG2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1528 On Wed, Jun 11, 2008 at 10:34:56PM -0400, Sebastien Roy wrote: > Although one might think that "eval" could be used in the shell to > access the set of values one line at a time, this has major pitfalls: > > * Each eval runs the risk possibly clobbering variables already in > use by the script. This means that any time a new field is > added, there is small but very real potential to break any > script that happened to use that field name as a local variable. This is not a problem: just document what variables it sets (and when you add new ones, have an option for selecting which ones to get). > * Use of eval presents a significant security risk: any command > where a non-privileged user might gain control over any field's > value makes eval as root (say, in an admin script) unsafe. To avoid this do: a) quote '$', '`' and a few other unsafe characters, b) instruct developers to disable globbing prior to evaluating this output. It should be possible to make dladm's output eval safe (and if not then let's find out why not). > Note that this is a change to a Committed interface, but it is a > relatively safe change. The Solaris 10 parseable output format was not I script around dladm output. (I take extra care for safety, and that's a pain, but it'd be better if dladm did that for me.) BTW, there's a similar issue with svcprop(1) output that I'm going to be proposing a fix for. We may want to set precedent. Nico -- From Nicolas.Williams@sun.com Thu Jun 12 00:29:39 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C7Tdre026932 for ; Thu, 12 Jun 2008 00:29:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5C7TVMo010339; Thu, 12 Jun 2008 15:29:35 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00I01A58Y400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 00:29:32 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C002E2A58QBF0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 00:29:32 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5C7TWGI013505; Thu, 12 Jun 2008 02:29:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5C7TWBK013504; Thu, 12 Jun 2008 02:29:32 -0500 (CDT) Date: Thu, 12 Jun 2008 02:29:31 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18512.38733.448019.247611@gargle.gargle.HOWL> To: Peter Memishian Cc: Darren Reed , Sebastien Roy , psarc-ext , John Leser Mail-followup-to: Peter Memishian , Darren Reed , Sebastien Roy , psarc-ext , John Leser Message-id: <20080612072931.GH2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 560 On Wed, Jun 11, 2008 at 11:26:05PM -0400, Peter Memishian wrote: > > > Please explain why using a whitespace character such as tab as the > > delimiter is unworkable. > > Because most shells will consolidate multiple consecutive whitespace > fields into a single field. Blank fields become unworkable. > > > My definition of parsable input means I can write a script like > > this in sh: > > > > dladm -o state,over | while read a b; do > > echo "a=$a,b=$b" > > done > > That works, just set IFS=| And would dladm quote '|' chars in ESSIDs? From peter.memishian@sun.com Thu Jun 12 00:37:03 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C7b3rh027139 for ; Thu, 12 Jun 2008 00:37:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5C7b2Gd000226 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 01:37:02 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00J03AHQUI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 00:37:02 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C002GXAHPQFE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 00:37:01 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5C7awPG033043; Thu, 12 Jun 2008 03:36:58 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5C7av32243620; Thu, 12 Jun 2008 03:36:57 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5C7avox243331; Thu, 12 Jun 2008 03:36:57 -0400 (EDT) Date: Thu, 12 Jun 2008 03:36:56 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080612072931.GH2735@Sun.COM> To: Nicolas Williams Cc: Peter Memishian , Darren Reed , Sebastien Roy , psarc-ext , John Leser Reply-to: peter.memishian@sun.com Message-id: <18512.53784.421481.777960@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <20080612072931.GH2735@Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 140 > > That works, just set IFS=| > > And would dladm quote '|' chars in ESSIDs? Yes. Please see the original case materials. -- meem From peter.memishian@sun.com Thu Jun 12 00:43:41 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C7heJb027173 for ; Thu, 12 Jun 2008 00:43:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5C7hWWa011596 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 08:43:39 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00K09ASQIX00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 00:43:38 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00K0LASPIT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 00:43:38 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5C7ha1P034385; Thu, 12 Jun 2008 03:43:36 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5C7haPP340333; Thu, 12 Jun 2008 03:43:36 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5C7haGx340296; Thu, 12 Jun 2008 03:43:36 -0400 (EDT) Date: Thu, 12 Jun 2008 03:43:36 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080612072824.GG2735@Sun.COM> To: Nicolas Williams Cc: Sebastien Roy , psarc-ext , John Leser , Peter Memishian Reply-to: peter.memishian@sun.com Message-id: <18512.54184.410858.731600@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080612072824.GG2735@Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 604 > > * Use of eval presents a significant security risk: any command > > where a non-privileged user might gain control over any field's > > value makes eval as root (say, in an admin script) unsafe. > > To avoid this do: a) quote '$', '`' and a few other unsafe characters, > b) instruct developers to disable globbing prior to evaluating this > output. It should be possible to make dladm's output eval safe (and if > not then let's find out why not). Please, let's not. The eval approach seemed clever at the time, but in retrospect it was a mistake. -- meem From Nicolas.Williams@sun.com Thu Jun 12 00:44:06 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C7i6Wd027185 for ; Thu, 12 Jun 2008 00:44:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5C7i3Yf016715; Thu, 12 Jun 2008 00:44:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C0050LATFDL00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 00:44:03 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C0019KATFK370@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 00:44:03 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5C7i3fc013535; Thu, 12 Jun 2008 02:44:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5C7i2sD013534; Thu, 12 Jun 2008 02:44:02 -0500 (CDT) Date: Thu, 12 Jun 2008 02:44:02 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18512.54184.410858.731600@gargle.gargle.HOWL> To: Peter Memishian Cc: Sebastien Roy , psarc-ext , John Leser Mail-followup-to: Peter Memishian , Sebastien Roy , psarc-ext , John Leser Message-id: <20080612074402.GJ2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080612072824.GG2735@Sun.COM> <18512.54184.410858.731600@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 711 On Thu, Jun 12, 2008 at 03:43:36AM -0400, Peter Memishian wrote: > > > > * Use of eval presents a significant security risk: any command > > > where a non-privileged user might gain control over any field's > > > value makes eval as root (say, in an admin script) unsafe. > > > > To avoid this do: a) quote '$', '`' and a few other unsafe characters, > > b) instruct developers to disable globbing prior to evaluating this > > output. It should be possible to make dladm's output eval safe (and if > > not then let's find out why not). > > Please, let's not. The eval approach seemed clever at the time, but in > retrospect it was a mistake. Because it was incomplete. From Nicolas.Williams@sun.com Thu Jun 12 00:46:03 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C7k3E8027222 for ; Thu, 12 Jun 2008 00:46:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5C7ju1U013049; Thu, 12 Jun 2008 08:46:01 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00I0RAWNRP00@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 01:45:59 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00FMCAWM2S20@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 01:45:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5C7jwOO013542; Thu, 12 Jun 2008 02:45:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5C7jwQ1013541; Thu, 12 Jun 2008 02:45:58 -0500 (CDT) Date: Thu, 12 Jun 2008 02:45:58 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080612074402.GJ2735@Sun.COM> To: Peter Memishian Cc: Sebastien Roy , psarc-ext , John Leser Mail-followup-to: Peter Memishian , Sebastien Roy , psarc-ext , John Leser Message-id: <20080612074558.GR2734@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080612072824.GG2735@Sun.COM> <18512.54184.410858.731600@gargle.gargle.HOWL> <20080612074402.GJ2735@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 971 On Thu, Jun 12, 2008 at 02:44:02AM -0500, Nicolas Williams wrote: > On Thu, Jun 12, 2008 at 03:43:36AM -0400, Peter Memishian wrote: > > > > > > * Use of eval presents a significant security risk: any command > > > > where a non-privileged user might gain control over any field's > > > > value makes eval as root (say, in an admin script) unsafe. > > > > > > To avoid this do: a) quote '$', '`' and a few other unsafe characters, > > > b) instruct developers to disable globbing prior to evaluating this > > > output. It should be possible to make dladm's output eval safe (and if > > > not then let's find out why not). > > > > Please, let's not. The eval approach seemed clever at the time, but in > > retrospect it was a mistake. > > Because it was incomplete. And incorrect, since it uses variable names like "BSSID/IBSSID". Given that I'm looking to fix similar issues in svcprop I think we should think about precedent. From kmcdonald@egenera.com Thu Jun 12 06:35:09 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CDZ8nL005129 for ; Thu, 12 Jun 2008 06:35:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CDZ66M038956; Thu, 12 Jun 2008 07:35:07 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00L03R2IZQ00@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 07:35:06 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00JCMR2IXO10@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 07:35:06 -0600 (MDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5CDZ5BL009814; Thu, 12 Jun 2008 13:35:06 +0000 (GMT) Received: from mms25es.mms.us.syntegra.com ([150.143.232.90] [150.143.232.90]) by relay22i.sun.com with ESMTP id BT-MMP-975808; Thu, 12 Jun 2008 13:35:05 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms25es.mms.us.syntegra.com with ESMTP id BT-MMP-29058150; Thu, 12 Jun 2008 13:35:05 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay21i.sun.com with ESMTP id BT-MMP-35997837; Thu, 12 Jun 2008 13:35:05 +0000 (Z) Received: from [192.168.101.160] ([24.107.237.206]) by webaccess.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jun 2008 09:33:04 -0400 Date: Thu, 12 Jun 2008 09:33:01 -0400 From: Kyle McDonald Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18512.38733.448019.247611@gargle.gargle.HOWL> To: peter.memishian@sun.com, psarc-ext Message-id: <4851258D.7080904@Egenera.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.045sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) X-OriginalArrivalTime: 12 Jun 2008 13:33:05.0064 (UTC) FILETIME=[D7F60280:01C8CC90] Status: RO Content-Length: 752 Peter Memishian wrote: > > Please explain why using a whitespace character such as tab as the > > delimiter is unworkable. > > Because most shells will consolidate multiple consecutive whitespace > fields into a single field. Blank fields become unworkable. > > > My definition of parsable input means I can write a script like > > this in sh: > > > > dladm -o state,over | while read a b; do > > echo "a=$a,b=$b" > > done > > That works, just set IFS=| > > Is ':' possibly used in the output values? If not, it seems that there is precedent (in other command output, and file formats) to make ':' preferable to '|'. If will regularly appear in the field values, then it can't work and '|' seems as good as anything else. -Kyle From dme@sun.com Thu Jun 12 06:42:01 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CDg1bT005182 for ; Thu, 12 Jun 2008 06:42:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CDg0aQ008516 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 06:42:01 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00C1DRDZMU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 06:41:59 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00KWBRDKTF80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 06:41:58 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5CDfiAb008027 for ; Thu, 12 Jun 2008 13:41:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2C00001QYNFA00@fe-emea-09.sun.com> (original mail from dme@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 14:41:44 +0100 (BST) Received: from [10.0.1.152] (host83-217-165-81.dsl.vispa.com [83.217.165.81]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2C00CQLRD9CQE0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 14:41:38 +0100 (BST) Date: Thu, 12 Jun 2008 14:41:21 +0100 From: David Edmondson Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851258D.7080904@Egenera.COM> Sender: David.Edmondson@sun.com To: Kyle McDonald Cc: Peter.Memishian@sun.com, psarc-ext Message-id: <28AF00A0-DFAB-4725-94EB-024D0FACBA8C@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.924) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <4851258D.7080904@Egenera.COM> Status: RO Content-Length: 128 On 12 Jun 2008, at 2:33pm, Kyle McDonald wrote: > Is ':' possibly used in the output values? As the original case says, yes. From John.Plocher@sun.com Thu Jun 12 06:48:26 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CDmQvw005483 for ; Thu, 12 Jun 2008 06:48:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CDmO0u016974 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 06:48:26 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00D0RROP7P00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 06:48:25 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00K5EROOT480@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 06:48:24 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5CDmO0g028337 for ; Thu, 12 Jun 2008 06:48:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2C00001RMSTM00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 06:48:24 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2C00M05ROO55G0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 06:48:24 -0700 (PDT) Date: Thu, 12 Jun 2008 06:48:24 -0700 From: John Plocher Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18512.45269.518979.218519@gargle.gargle.HOWL> Sender: John.Plocher@sun.com To: Peter.Memishian@sun.com Cc: Darren Reed , psarc-ext , Sebastien Roy , John Leser Message-id: <48512928.6000600@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 794 Design nit: For the choice of delimiter, if the "read" routines already handle the escape sequences AND you are generating all the output, you could as easily generate MAC addrs in an escaped form and the consuming shell wouldn't need to care. (yes, MAC addrs of the form xx\:yy\:zz would show up in the output stream, but (other than being ugly) would add no effective complexity to their use...) Architectural "bigger than nit": The question of having a common "parsable format" across all of the various OpenSolaris utilities -vs- per utility and/or per-family quirks and gratuitous differences *IS* an architectural issue. IMHO, there should be utility code in the system that both generates AND parses a common format so everyone does not end up reinventing this wheel. -John From peter.memishian@sun.com Thu Jun 12 08:30:37 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CFUbl0011682 for ; Thu, 12 Jun 2008 08:30:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CFUXNw016573 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 09:30:36 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C0001NWEZMO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 08:30:35 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00L2QWEZII50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 08:30:35 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CFUV03017960; Thu, 12 Jun 2008 11:30:31 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5CFUU9E265451; Thu, 12 Jun 2008 11:30:30 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5CFUUgt265272; Thu, 12 Jun 2008 11:30:30 -0400 (EDT) Date: Thu, 12 Jun 2008 11:30:29 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48512928.6000600@Sun.Com> To: John Plocher Cc: peter.memishian@sun.com, Darren Reed , psarc-ext , Sebastien Roy , John Leser Reply-to: peter.memishian@sun.com Message-id: <18513.16661.818160.548733@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 2496 > For the choice of delimiter, if the "read" routines already handle > the escape sequences AND you are generating all the output, you could > as easily generate MAC addrs in an escaped form and the consuming > shell wouldn't need to care. (yes, MAC addrs of the form xx\:yy\:zz > would show up in the output stream, but (other than being ugly) would > add no effective complexity to their use...) That's a good point, especially since the output is intended only for scripts (which won't be offended by the escapes), and using : is slightly easier for scripts since IFS=: doesn't require any quoting, but IFS='|' requires the surrounding single-quotes (as shown) to not be misparsed by the shell. John (Leser): what do you think? > Architectural "bigger than nit": > > The question of having a common "parsable format" across all of the > various OpenSolaris utilities -vs- per utility and/or per-family > quirks and gratuitous differences *IS* an architectural issue. IMHO, > there should be utility code in the system that both generates AND > parses a common format so everyone does not end up reinventing this > wheel. One of the benefits of having the format be easy for shells is that the shell provides the parsing utility code -- as per my earlier example, this really should be trivial. The only bit of complexity would be picking out which items one was really interested in, which depends on what the consumer is trying to do, and on what fields in that particular output format form the unique "key"[1]. So I don't think there's much to reinvent there. As for the generation code: in my experience, this is harder than it seems because (among other things) the APIs one would need depend on the way the utility producing the output is structured -- many existing utilities are built to print the data a cell at a time, whereas others print a row at a time, and still others gather all the information first and then print a table. That said, I have built some mostly-generic row-at-a-time routines for ipmpstat that I'd be willing to generalize further and package up into a reuseable API if folks are interested. But it's not easy to create a simple API that completely separates the parsing machinery from the data collection, so I'd like to get some more experience with it and later run it as a follow-on case. [1] For instance, show-link has a unique key of LINK, whereas show-linkprop requires LINK and PROPERTY to form a unique key. -- meem From peter.memishian@sun.com Thu Jun 12 08:36:30 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CFaTB4011936 for ; Thu, 12 Jun 2008 08:36:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CFaRGl011524 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 16:36:28 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00709WOQ3B00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:36:26 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00J5OWOOXO90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:36:24 -0600 (MDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CFaK9W019912; Thu, 12 Jun 2008 11:36:20 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5CFaK2G331738; Thu, 12 Jun 2008 11:36:20 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5CFaKhM331733; Thu, 12 Jun 2008 11:36:20 -0400 (EDT) Date: Thu, 12 Jun 2008 11:36:20 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18513.16661.818160.548733@gargle.gargle.HOWL> To: peter.memishian@sun.com Cc: John Plocher , Darren Reed , psarc-ext , Sebastien Roy , John Leser Reply-to: peter.memishian@sun.com Message-id: <18513.17012.764353.894164@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <18513.16661.818160.548733@gargle.gargle.HOWL> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1068 > As for the generation code: in my experience, this is harder than it seems > because (among other things) the APIs one would need depend on the way the > utility producing the output is structured -- many existing utilities are > built to print the data a cell at a time, whereas others print a row at a > time, and still others gather all the information first and then print a > table. That said, I have built some mostly-generic row-at-a-time routines > for ipmpstat that I'd be willing to generalize further and package up into > a reuseable API if folks are interested. But it's not easy to create a > simple API that completely separates the parsing machinery from the data Sorry, I meant to say "output machinery". Note that the API handles all aspects of output, not just parseable output. > collection, so I'd like to get some more experience with it and later run > it as a follow-on case. > > [1] For instance, show-link has a unique key of LINK, whereas > show-linkprop requires LINK and PROPERTY to form a unique key. -- meem From John.Plocher@sun.com Thu Jun 12 08:56:25 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CFuPGv012606 for ; Thu, 12 Jun 2008 08:56:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CFuMOK021669 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 16:56:24 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C0021HXLZAO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 08:56:23 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C000H7XLYJV90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 08:56:22 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5CFuLV4010736 for ; Thu, 12 Jun 2008 08:56:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2C00301VRNQ700@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 08:56:21 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2C00LCIXLUAQD0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 08:56:18 -0700 (PDT) Date: Thu, 12 Jun 2008 08:56:17 -0700 From: John Plocher Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18513.16661.818160.548733@gargle.gargle.HOWL> Sender: John.Plocher@sun.com To: Peter.Memishian@sun.com Cc: Darren Reed , psarc-ext , Sebastien Roy , John Leser Message-id: <48514721.6070902@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <18513.16661.818160.548733@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 1518 Peter Memishian wrote: > > Architectural "bigger than nit": > > > > The question of having a common "parsable format" across > As for the generation code: in my experience, this is harder My frustration is that we don't have a "grammer" for this parsable format that can be used as a design pattern for ALL of our utilities. This leads to statements like Seb's (from his original proposal): We propose that parseable output ... similar to ... I don't want dozens of OpenSolaris utilities that all support some form of "-o" and "-p" CLI arguments to all generate output grammars that are similar to (but not quite exactly the same as) all the others. Hmm, this is dladm, so my parser needs to have IFS='|', while later in my script the one that uses zoneadm needs IFS=: and this other place needs eval (but has namespace issues) - except on Fridays when the user has a locale != "C" ... You are right - expecting a common set of code is probably not worthwhile, but having a common grammar/format (IMO) still is. I think we have enuf stuff in the system already that uses ":" delimited lists, one line per item, with ":", "\" and "\n" escaped by "\" characters that we need to stick with it as a standard - but someone needs to do the survey and make a case to make it so. Maybe not this case, but there is a TC* lurking here to be exactly the same as whatever that standard turns out to be. As well as a set of new projects to retrofit all the others to comply as well. -John From gdamore@sun.com Thu Jun 12 08:58:19 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CFwJjP012693 for ; Thu, 12 Jun 2008 08:58:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CFwEqD027544 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 08:58:19 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C0080FXP5IB00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:58:17 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00JNRXP5XNA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:58:17 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5CFwHCx010957 for ; Thu, 12 Jun 2008 08:58:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2C00B01XAQJR00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 08:58:17 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2C00LCZXP3AQE0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 08:58:16 -0700 (PDT) Date: Thu, 12 Jun 2008 08:57:16 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48512928.6000600@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Peter.Memishian@sun.com, Darren Reed , psarc-ext , Sebastien Roy , John Leser Message-id: <4851475C.1090403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 906 John Plocher wrote: > Design nit: > > For the choice of delimiter, if the "read" routines already handle > the escape sequences AND you are generating all the output, you could > as easily generate MAC addrs in an escaped form and the consuming > shell wouldn't need to care. (yes, MAC addrs of the form xx\:yy\:zz > would show up in the output stream, but (other than being ugly) would > add no effective complexity to their use...) > > > Architectural "bigger than nit": > > The question of having a common "parsable format" across all of the > various OpenSolaris utilities -vs- per utility and/or per-family > quirks and gratuitous differences *IS* an architectural issue. IMHO, > there should be utility code in the system that both generates AND > parses a common format so everyone does not end up reinventing this > wheel. I have three letters, which may be unpopular: X-M-L -- Garrett From Sebastien.Roy@Sun.COM Thu Jun 12 09:04:26 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CG4QuT012970 for ; Thu, 12 Jun 2008 09:04:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CG4PZT000144 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 09:04:26 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C0010ZXZEMC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:04:26 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00LASXZDI960@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:04:25 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5CG4P98006314 for ; Thu, 12 Jun 2008 16:04:25 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2C00G01WCZ6N00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 10:04:25 -0600 (MDT) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2C0016DXYUGG60@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 10:04:07 -0600 (MDT) Date: Thu, 12 Jun 2008 12:04:05 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851475C.1090403@sun.com> Sender: Sebastien.Roy@Sun.COM To: "Garrett D'Amore" Cc: John Plocher , Peter.Memishian@Sun.COM, Darren Reed , psarc-ext , John Leser Message-id: <1213286645.1150.6.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> Status: RO Content-Length: 258 On Thu, 2008-06-12 at 08:57 -0700, Garrett D'Amore wrote: > I have three letters, which may be unpopular: > > X-M-L This isn't easily parseable from a shell. Also, let's not design the system by committee in the context of this PSARC case please. -Seb From John.Plocher@Sun.COM Thu Jun 12 09:16:24 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CGGO9M013539 for ; Thu, 12 Jun 2008 09:16:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CGGNY3033479 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 10:16:24 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00201YJA0F00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:16:22 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C00LECYJAIL80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:16:22 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5CGGMZA014327 for ; Thu, 12 Jun 2008 09:16:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2C00501XHPJ300@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:16:22 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2C00BEWYIXLC20@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 09:16:09 -0700 (PDT) Date: Thu, 12 Jun 2008 09:16:08 -0700 From: John Plocher Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851475C.1090403@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Peter.Memishian@Sun.COM, Darren Reed , psarc-ext , Sebastien Roy , John Leser Message-id: <48514BC8.50302@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 1114 Garrett D'Amore wrote: > I have three letters, which may be unpopular: > > X-M-L If a goal is easy parsability with sh scripts, this fails a basic sanity test - unless one uses Roland's TBD libcompoundvar.so.1 If shell parsing wasn't a goal, I'd push JSON or csv formats; things that are too complicated for such a tabular representation are probably not really good candidates for the "-p -o xx,yy,zz" design pattern... On the other hand, take a look at what Yahoo has done with their Pipes concept to decouple the source format from the content: http://pipes.yahoo.com/pipes/ Pipes is a powerful composition tool to aggregate, manipulate, and mashup content from around the web. Like Unix pipes, simple commands can be combined together to create output that meets your needs: * combine many feeds into one, then sort, filter and translate it. * geocode your favorite feeds and browse the items on an interactive map. * power widgets/badges on your web site. * grab the output of any Pipes as RSS, JSON, KML, and other formats. -John From jek3@Sun.COM Thu Jun 12 11:51:36 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CIpaBm018472 for ; Thu, 12 Jun 2008 11:51:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CIpWCF018045; Thu, 12 Jun 2008 11:51:33 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00L095PW7300@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 12:51:32 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00D8R5PV9D70@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 12:51:31 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5CIpUgi477935; Thu, 12 Jun 2008 11:51:30 -0700 (PDT) Date: Thu, 12 Jun 2008 08:54:13 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <1213286645.1150.6.camel@strat> To: Sebastien Roy Cc: "Garrett D'Amore" , John Plocher , Peter.Memishian@Sun.COM, Darren Reed , psarc-ext , John Leser Message-id: <485170D5.6080300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 894 Sebastien Roy wrote: > On Thu, 2008-06-12 at 08:57 -0700, Garrett D'Amore wrote: > >> I have three letters, which may be unpopular: >> >> X-M-L >> > > This isn't easily parseable from a shell. Also, let's not design the > system by committee in the context of this PSARC case please. > > -Seb > +1 That said, two things,... 1) As this seems to be heading for "invention", try to do so inclusive of the external developers. 2) Try to avoid invention. IMO the best "invention" comes from the virtual stone age --- use unique flags to deliver unique tokens. Think "uname": $ uname -a SunOS hawaiin-sun 5.11 snv_85 i86pc i386 i86pc Yeech: $ FOO=`uname -a | ` Much better: $ FOO=`uname -n` Its much easier and more robust to do the token generation in the utility than in some error prone (and re-invented) shell parsing. - jek3 From Gordon.Ross@sun.com Thu Jun 12 12:12:44 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CJChck019281 for ; Thu, 12 Jun 2008 12:12:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CJCg9V002114 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 12:12:43 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D009076P63100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 12:12:42 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D006OE6P57M70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 12:12:41 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5CJCfMt006956 for ; Thu, 12 Jun 2008 19:12:41 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2D0010163K6B00@mail-amer.sun.com> (original mail from Gordon.Ross@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 13:12:41 -0600 (MDT) Received: from [129.148.168.97] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2D0059F6OZBJ00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 13:12:36 -0600 (MDT) Date: Thu, 12 Jun 2008 15:12:31 -0400 From: Gordon Ross Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48514721.6070902@Sun.Com> Sender: Gordon.Ross@sun.com To: John Plocher Cc: Peter.Memishian@sun.com, Darren Reed , psarc-ext , Sebastien Roy , John Leser Message-id: <1213297951.1237.23.camel@acer-gwr> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <18513.16661.818160.548733@gargle.gargle.HOWL> <48514721.6070902@Sun.Com> Status: RO Content-Length: 859 Some utilities use XML output too, i.e. lustatus -X Great extensibility, self-describing, etc. but not easy to parse with shell scripts... Gordon > Peter Memishian wrote: > > > Architectural "bigger than nit": > > > > > > The question of having a common "parsable format" across > > > As for the generation code: in my experience, this is harder > > My frustration is that we don't have a "grammer" for this > parsable format that can be used as a design pattern for ALL > of our utilities. This leads to statements like Seb's (from > his original proposal): > > We propose that parseable output ... similar to ... > > I don't want dozens of OpenSolaris utilities that all support > some form of "-o" and "-p" CLI arguments to all generate output > grammars that are similar to (but not quite exactly the same as) > all the others. [...] From Darren.Reed@sun.com Thu Jun 12 13:15:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CKFshn023167 for ; Thu, 12 Jun 2008 13:15:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CKFo4Y019398 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 21:15:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00B079MGPN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 12 Jun 2008 13:15:52 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D0067M9MF7MF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 12 Jun 2008 13:15:52 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5CKGFJV002003 for ; Thu, 12 Jun 2008 20:16:15 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K2D00I01998CS00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 04:14:09 +0800 (SGT) Received: from [192.168.200.10] ([76.191.150.176]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K2D00FEW9JIR12A@mail-apac.sun.com>; Fri, 13 Jun 2008 04:14:09 +0800 (SGT) Date: Thu, 12 Jun 2008 13:15:43 -0700 From: Darren Reed Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <485170D5.6080300@sun.com> Sender: Darren.Reed@sun.com To: Joseph Kowalski Cc: Sebastien Roy , "Garrett D'Amore" , John Plocher , Peter.Memishian@sun.com, psarc-ext , John Leser Message-id: <485183EF.9040809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) Status: RO Content-Length: 1316 Joseph Kowalski wrote: > Sebastien Roy wrote: >> On Thu, 2008-06-12 at 08:57 -0700, Garrett D'Amore wrote: >> >>> I have three letters, which may be unpopular: >>> >>> X-M-L >>> >> >> This isn't easily parseable from a shell. Also, let's not design the >> system by committee in the context of this PSARC case please. >> >> -Seb >> > > +1 > > That said, two things,... > > 1) As this seems to be heading for "invention", try to do so > inclusive of the external developers. > > 2) Try to avoid invention. IMO the best "invention" comes from > the virtual stone age --- use unique flags to deliver unique tokens. > Think "uname": > > $ uname -a > SunOS hawaiin-sun 5.11 snv_85 i86pc i386 i86pc > > Yeech: > > $ FOO=`uname -a | ` > > Much better: > > $ FOO=`uname -n` > > Its much easier and more robust to do the token generation in the > utility than in some error prone (and re-invented) shell parsing. Since they've already got the ability to print a single field... What it sounds like to me, is that you're suggesting that rather than utilities automatically use a particular field separator, they should use white space (of some kind) unless they're told to use another character. This falls in line with the behaviour of tools like awk, cut, etc. Darren From peter.memishian@sun.com Thu Jun 12 14:00:32 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CL0WFg029961 for ; Thu, 12 Jun 2008 14:00:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CL0VIc001906 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 15:00:32 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00D61BOUEQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 14:00:30 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00BIIBORQW40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 14:00:28 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CL0ObF052744; Thu, 12 Jun 2008 17:00:24 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5CL0OCO709202; Thu, 12 Jun 2008 17:00:24 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5CKvucI696140; Thu, 12 Jun 2008 16:57:56 -0400 (EDT) Date: Thu, 12 Jun 2008 16:57:56 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48514721.6070902@Sun.Com> To: John Plocher Cc: peter.memishian@sun.com, Darren Reed , psarc-ext , Sebastien Roy , John Leser Reply-to: peter.memishian@sun.com Message-id: <18513.36308.494782.645830@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <18513.16661.818160.548733@gargle.gargle.HOWL> <48514721.6070902@Sun.Com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1152 > Hmm, this is dladm, so my parser needs to have IFS='|', whilea > later in my script the one that uses zoneadm needs IFS=: and > this other place needs eval (but has namespace issues) - except > on Fridays when the user has a locale != "C" ... > > You are right - expecting a common set of code is probably not > worthwhile, but having a common grammar/format (IMO) still is. I think it's worthwhile too, but this case is considerably more modest in its goals: we simply want dladm to be easy to parse in the shell and other simple-minded traditional Unix utilities. We believe the simple approach we're proposing with this case are generally applicable to future utilities and thus would others inventing paresable output modes that need to be shell-friendly to follow the same appraoch. We also expect that future networking CLIs we're working on (flowadm, ipmpstat, lbadm, ...) will look quite similar, but that's as far as we're comfortable going given both the political and technical obstacles (not just in terms of legacy code, but in terms of differing requirements) to building a truly uniform solution. -- meem From carlsonj@phorcys.east.sun.com Thu Jun 12 14:10:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CLAhrl001479 for ; Thu, 12 Jun 2008 14:10:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CLAa3w013951; Thu, 12 Jun 2008 22:10:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00D01C5OSV00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 14:10:37 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00BU0C5OR340@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 14:10:36 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5CLAZbY016062; Thu, 12 Jun 2008 17:10:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5CLAZbB016059; Thu, 12 Jun 2008 17:10:35 -0400 (EDT) Date: Thu, 12 Jun 2008 17:10:35 -0400 From: James Carlson Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18513.36308.494782.645830@gargle.gargle.HOWL> To: Peter.Memishian@sun.com Cc: John Plocher , psarc-ext , Sebastien Roy , John Leser , Darren Reed Message-id: <18513.37067.788251.708607@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <18513.16661.818160.548733@gargle.gargle.HOWL> <48514721.6070902@Sun.Com> <18513.36308.494782.645830@gargle.gargle.HOWL> Status: RO Content-Length: 1656 Peter Memishian writes: > > Hmm, this is dladm, so my parser needs to have IFS='|', whilea > > later in my script the one that uses zoneadm needs IFS=: and > > this other place needs eval (but has namespace issues) - except > > on Fridays when the user has a locale != "C" ... > > > > You are right - expecting a common set of code is probably not > > worthwhile, but having a common grammar/format (IMO) still is. > > I think it's worthwhile too, but this case is considerably more modest in > its goals: we simply want dladm to be easy to parse in the shell and other > simple-minded traditional Unix utilities. We believe the simple approach > we're proposing with this case are generally applicable to future > utilities and thus would others inventing paresable output modes that need > to be shell-friendly to follow the same appraoch. We also expect that > future networking CLIs we're working on (flowadm, ipmpstat, lbadm, ...) > will look quite similar, but that's as far as we're comfortable going > given both the political and technical obstacles (not just in terms of > legacy code, but in terms of differing requirements) to building a truly > uniform solution. For what it's worth, the colon-separated (and escaped) output method of resolving this problem is what I did for zoneadm in PSARC 2006/387 and CR 6431731, and for exactly the same reasons. There's at least some precedent here. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From peter.memishian@sun.com Thu Jun 12 14:15:32 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CLFWKW001697 for ; Thu, 12 Jun 2008 14:15:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CLFVp8007378 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 14:15:31 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00E0DCDT0D00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 14:15:29 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00BDGCDRQV40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 14:15:28 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CLFOXm061858; Thu, 12 Jun 2008 17:15:24 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5CLFOBa787486; Thu, 12 Jun 2008 17:15:24 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5CL6lf6741629; Thu, 12 Jun 2008 17:06:47 -0400 (EDT) Date: Thu, 12 Jun 2008 17:06:47 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18513.36308.494782.645830@gargle.gargle.HOWL> To: peter.memishian@sun.com Cc: John Plocher , Darren Reed , psarc-ext , Sebastien Roy , John Leser Reply-to: peter.memishian@sun.com Message-id: <18513.36839.796854.755327@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <18513.16661.818160.548733@gargle.gargle.HOWL> <48514721.6070902@Sun.Com> <18513.36308.494782.645830@gargle.gargle.HOWL> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1007 Ack, my reply got kinda garbled by hasty revisions -- one more time: > > You are right - expecting a common set of code is probably not > > worthwhile, but having a common grammar/format (IMO) still is. I think it's worthwhile too, but this case is considerably more modest in its goals: we simply want dladm to be easy to parse in the shell and with other simple-minded traditional Unix utilities. We believe the simple approach we're proposing with this case is generally applicable to future utilities and thus would encourage others inventing parsable output modes that need to be shell-friendly to follow the same approach. We also expect that future networking CLIs we're working on (flowadm, ipmpstat, lbadm, ...) will look quite similar, but that's as far as we're comfortable going given both the political and technical obstacles (not just in terms of legacy code, but in terms of differing requirements) that stand in the way of a truly uniform solution. -- meem From peter.memishian@sun.com Thu Jun 12 14:15:32 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CLFWa1001701 for ; Thu, 12 Jun 2008 14:15:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CLFVpA007378; Thu, 12 Jun 2008 14:15:31 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00E0FCDT0D00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 14:15:29 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00BRXCDRQZ40@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 14:15:28 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5CLFO9N061859; Thu, 12 Jun 2008 17:15:24 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5CLFOBc787486; Thu, 12 Jun 2008 17:15:24 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5CL2kdI721386; Thu, 12 Jun 2008 17:02:46 -0400 (EDT) Date: Thu, 12 Jun 2008 17:02:46 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <485183EF.9040809@Sun.COM> To: Darren Reed Cc: Joseph Kowalski , Sebastien Roy , "Garrett D'Amore" , John Plocher , peter.memishian@sun.com, psarc-ext , John Leser Reply-to: peter.memishian@sun.com Message-id: <18513.36598.728002.583555@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 626 > What it sounds like to me, is that you're suggesting that rather than > utilities automatically use a particular field separator, they should > use white space (of some kind) unless they're told to use another > character. Which (again) doesn't work if you need to have empty fields, which is quite common (and no, we must not corrupt data by changing empty values to another token). > This falls in line with the behaviour of tools like awk, cut, etc. All of those commands allow a field separator to be specified. I stand by the original proposal (modulo whether the field separator should be : or |). -- meem From jek3@sun.com Thu Jun 12 15:00:08 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CM07vY006185 for ; Thu, 12 Jun 2008 15:00:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5CLxvA9007341; Fri, 13 Jun 2008 06:00:02 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00C0DEG0B900@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 16:00:00 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D008Q9EFZO990@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 15:59:59 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5CLxwdS510684; Thu, 12 Jun 2008 14:59:58 -0700 (PDT) Date: Thu, 12 Jun 2008 12:02:42 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <485183EF.9040809@Sun.COM> To: Darren Reed Cc: Sebastien Roy , "Garrett D'Amore" , John Plocher , Peter.Memishian@sun.com, psarc-ext , John Leser Message-id: <48519D02.90902@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 2025 Darren Reed wrote: >> Its much easier and more robust to do the token generation in the >> utility than in some error prone (and re-invented) shell parsing. > > Since they've already got the ability to print a single field... That would have been an interesting factoid to include in the presentation. > > What it sounds like to me, is that you're suggesting that rather than > utilities automatically use a particular field separator, they should > use white space (of some kind) unless they're told to use another > character. > > This falls in line with the behaviour of tools like awk, cut, etc. No, I was suggesting what I said. However, this caused me to re-read the proposal. I have *several* observations: 1. May I please have a set of diffs on the man page? I found some bits of the proposal a bit ambiguous and this is probably the easiest to way to resolve them. 2. " It also proposes a set of guidelines that we anticipate future networking CLIs will follow (and, where appropriate and feasible, could be applied to existing CLIs)." I found no guideslines - only a specific example. (I suggest that you just delete this line - guidelines in this context will probably result in enough discussion to result in a derail - heck, there is enough discussion already without the "guideline" assertion.) 3. "Although one might think that "eval" could be used in the shell to access the set of values one line at a time, this has major pitfalls:" There are lots of ways to parse in shell. If you are wary of eval, pick another. The "evil of eval" is not relevant to this case. 4. "Note that this is a change to a Committed interface,..." I understand the rationale, but I believe this makes the binding "Minor:S11", not just "Minor". (OK, its a nit,...) 5. MOST IMPORTANTLY, this utility already provides the "-o" option. Why isn't it the best way to write the scripts you are proposing? - jek3 From Nicolas.Williams@sun.com Thu Jun 12 15:07:53 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CM7qm2007031 for ; Thu, 12 Jun 2008 15:07:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CM7n3n022482; Thu, 12 Jun 2008 15:07:49 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00H05ET1W200@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 15:07:49 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D006CIET0L2C0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 15:07:49 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5CM7mh2019629; Thu, 12 Jun 2008 17:07:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5CM7mWZ019628; Thu, 12 Jun 2008 17:07:48 -0500 (CDT) Date: Thu, 12 Jun 2008 17:07:48 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48519D02.90902@sun.com> To: Joseph Kowalski Cc: Darren Reed , Sebastien Roy , "Garrett D'Amore" , John Plocher , Peter.Memishian@sun.com, psarc-ext , John Leser Mail-followup-to: Joseph Kowalski , Darren Reed , Sebastien Roy , Garrett D'Amore , John Plocher , Peter.Memishian@sun.com, psarc-ext , John Leser Message-id: <20080612220747.GY2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1161 On Thu, Jun 12, 2008 at 12:02:42PM -1000, Joseph Kowalski wrote: I second everything you just wrote. > 2. " It also proposes a set of guidelines that we anticipate future > networking CLIs will follow (and, where appropriate and > feasible, could be applied to existing CLIs)." > > I found no guideslines - only a specific example. (I suggest > that you just delete this line - guidelines in this context will > probably result in enough discussion to result in a derail - > heck, there is enough discussion already without the "guideline" > assertion.) Indeed, but nonetheless the case may set precedent, no? > 3. "Although one might think that "eval" could be used in the shell to > access the set of values one line at a time, this has major pitfalls:" > > There are lots of ways to parse in shell. If you are wary of eval, > pick another. The "evil of eval" is not relevant to this case. I refuted those pitfalls too (though it's crucial to get the quoting rules right). One thing I hear is that there's a desire to obsolete and remove eval. Well, that'd get my attention. Nico -- From John.Leser@sun.com Thu Jun 12 16:25:45 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5CNPj8N014696 for ; Thu, 12 Jun 2008 16:25:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5CNPfIw027358 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 16:25:45 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00H1LIEWJH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 17:25:44 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00ES5IEU1720@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 17:25:42 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5CNPf3k017109 for ; Thu, 12 Jun 2008 23:25:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2D00B01I643600@mail-amer.sun.com> (original mail from John.Leser@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 17:25:42 -0600 (MDT) Received: from [192.168.1.92] ([66.31.65.119]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2D00AALIEPE8G0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 17:25:41 -0600 (MDT) Date: Thu, 12 Jun 2008 19:25:37 -0400 From: John Leser Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18513.16661.818160.548733@gargle.gargle.HOWL> Sender: John.Leser@sun.com To: Peter.Memishian@sun.com Cc: John Plocher , Darren Reed , psarc-ext , Sebastien Roy Message-id: <4851B071.30905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <18513.16661.818160.548733@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 863 Peter Memishian wrote: > > For the choice of delimiter, if the "read" routines already handle > > the escape sequences AND you are generating all the output, you could > > as easily generate MAC addrs in an escaped form and the consuming > > shell wouldn't need to care. (yes, MAC addrs of the form xx\:yy\:zz > > would show up in the output stream, but (other than being ugly) would > > add no effective complexity to their use...) > > That's a good point, especially since the output is intended only for > scripts (which won't be offended by the escapes), and using : is slightly > easier for scripts since IFS=: doesn't require any quoting, but IFS='|' > requires the surrounding single-quotes (as shown) to not be misparsed by > the shell. John (Leser): what do you think? > I'm fine with ':', especially give that zoneadm already uses it. -John From John.Leser@sun.com Thu Jun 12 17:21:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D0L09S018677 for ; Thu, 12 Jun 2008 17:21:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D0KsiH023314 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 08:20:59 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00M03KYV4I00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 17:20:55 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00BTWKYVQVE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 17:20:55 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5D0Kt2k023844 for ; Fri, 13 Jun 2008 00:20:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2D00901KVZHY00@mail-amer.sun.com> (original mail from John.Leser@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 18:20:54 -0600 (MDT) Received: from [192.168.1.92] ([66.31.65.119]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2D00DYSKYSI860@mail-amer.sun.com>; Thu, 12 Jun 2008 18:20:54 -0600 (MDT) Date: Thu, 12 Jun 2008 20:20:52 -0400 From: John Leser Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48519D02.90902@sun.com> Sender: John.Leser@sun.com To: Joseph Kowalski Cc: Darren Reed , Sebastien Roy , "Garrett D'Amore" , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <4851BD64.4060405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 4787 Joseph Kowalski wrote: > Darren Reed wrote: >>> Its much easier and more robust to do the token generation in the >>> utility than in some error prone (and re-invented) shell parsing. >> >> Since they've already got the ability to print a single field... > > > That would have been an interesting factoid to include in the presentation. > >> >> What it sounds like to me, is that you're suggesting that rather than >> utilities automatically use a particular field separator, they should >> use white space (of some kind) unless they're told to use another >> character. >> >> This falls in line with the behaviour of tools like awk, cut, etc. > > > No, I was suggesting what I said. > > However, this caused me to re-read the proposal. I have *several* > observations: > > 1. May I please have a set of diffs on the man page? I found some > bits of the > proposal a bit ambiguous and this is probably the easiest to way to > resolve > them. > We've tried to make the proposal as specific and detailed as possible, and have certainly provide more examples than a typical man page (look at the usage of zoneadm list in the zoneadm man page which is documenting essentially the same syntax we are proposing, minus the -o option). I'd rather directly address any specific areas of ambiguity you see. > 2. " It also proposes a set of guidelines that we anticipate future > networking > CLIs will follow (and, where appropriate and feasible, could be > applied > to existing CLIs)." > > I found no guideslines - only a specific example. (I suggest that > you just > delete this line - guidelines in this context will probably result > in enough > discussion to result in a derail - heck, there is enough discussion > already > without the "guideline" assertion.) > We're proposing a particular way of doing things with the idea that future CLI tools will do the same thing unless they have a substantial reason for not doing so. I think the word "guideline" was used to avoid words like "requirement" which implies all sorts of nasty process. Sorry if it caused confusion. > 3. "Although one might think that "eval" could be used in the shell to > access the set of values one line at a time, this has major pitfalls:" > > There are lots of ways to parse in shell. If you are wary of eval, > pick another. The "evil of eval" is not relevant to this case. > I agree that an eval based system could work, but it requires extra care (as Nicolas has pointed out) in both the production and consumption of the parseable output, without any advantages I'm aware of. The "evil of eval" is relevant to explain our choice to not produce output designed for consumption by a script using "eval", which is the way dladm currently works. > 4. "Note that this is a change to a Committed interface,..." > > I understand the rationale, but I believe this makes the binding > "Minor:S11", > not just "Minor". (OK, its a nit,...) > > 5. MOST IMPORTANTLY, this utility already provides the "-o" option. > Why isn't it the best way to write the scripts you are proposing? > Let me see if understand you. I'll use "zoneadm list" as an example because it's the closest thing to an existing implementation of our proposal. Right now, I do: # zoneadm list -p 0:global:running:/::native:shared 3:mathesar-tz1:running:/export/home/zones/mathesar-tz1:57e4d1c9-cb85-c882-875e-84f1a50fa95d:native:shared This produces a set of (2) records records. You're suggesting that with the -o option, this sort of output is not necessary, because I could just request the specific fields I wanted, one at a time, without having to worry about field separators, field ordering, etc. So I would do something like: # zoneadm -z global list -o status running (note this doesn't actually work because zoneadm doesn't support -o) I agree that this would be adequate for many purposes, but there are significant limitations: * primary keys: zoneadm allows only zone name as the primary key to look up data. Lets say my script wants to figure what zone path is associated with a particular zone uuid. This would require some extra work. In general, we'd need to anticipate what fields will be needed as lookup keys and provide a way to do that for our utilities. * multiple calls: You have to call the utility once for each field you want. This can add up if a script wants to iterate over every zone on the system and there are 100s or 1000s of them. Our proposed syntax piped into "while read" generally requires only one call. If the state of the system changes between calls, the script will not get a coherent set of data from multiple calls. -John > - jek3 > > From Darren.Reed@sun.com Thu Jun 12 17:36:28 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D0aRBj018999 for ; Thu, 12 Jun 2008 17:36:27 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D0aICq027941 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 08:36:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00B05LOMBF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 17:36:22 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D0021ZLOLSH30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 17:36:22 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5D0bErW019591 for ; Fri, 13 Jun 2008 00:37:15 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K2D00801LHIXJ00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 08:34:39 +0800 (SGT) Received: from [10.0.232.239] ([192.18.41.196]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K2D00FR2LLKQY6B@mail-apac.sun.com>; Fri, 13 Jun 2008 08:34:36 +0800 (SGT) Date: Thu, 12 Jun 2008 17:36:08 -0700 From: Darren Reed Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18513.36598.728002.583555@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: Peter.Memishian@sun.com Cc: Joseph Kowalski , Sebastien Roy , "Garrett D'Amore" , John Plocher , psarc-ext , John Leser Message-id: <4851C0F8.4090402@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <18513.36598.728002.583555@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) Status: RO Content-Length: 922 Peter Memishian wrote: > > What it sounds like to me, is that you're suggesting that rather than > > utilities automatically use a particular field separator, they should > > use white space (of some kind) unless they're told to use another > > character. > > Which (again) doesn't work if you need to have empty fields, which is > quite common (and no, we must not corrupt data by changing empty values to > another token). > An interesting statement given that many text file formats do indeed have some sort of token/symbol to indicate "NULL", so it isn't as insurmountable as is being suggested. > > This falls in line with the behaviour of tools like awk, cut, etc. > > All of those commands allow a field separator to be specified. Yes and that was the purpose of mentioning them - to suggest the idea that perhaps the field separator should be chosen by the user and if not, whitespace used. Darren From John.Leser@sun.com Thu Jun 12 18:06:06 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D165ED020334 for ; Thu, 12 Jun 2008 18:06:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D15twE008948 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 09:06:05 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D0010RN24F700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 19:06:04 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00ER9N231150@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 19:06:04 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5D163Su013418 for ; Fri, 13 Jun 2008 01:06:03 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2D00J01MVCH900@mail-amer.sun.com> (original mail from John.Leser@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 19:06:03 -0600 (MDT) Received: from [192.168.1.92] ([66.31.65.119]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2D00FCSN1Q3120@mail-amer.sun.com>; Thu, 12 Jun 2008 19:05:52 -0600 (MDT) Date: Thu, 12 Jun 2008 21:05:50 -0400 From: John Leser Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851C0F8.4090402@Sun.COM> Sender: John.Leser@sun.com To: Darren Reed Cc: Peter.Memishian@sun.com, Joseph Kowalski , Sebastien Roy , "Garrett D'Amore" , John Plocher , psarc-ext Message-id: <4851C7EE.20704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <18513.36598.728002.583555@gargle.gargle.HOWL> <4851C0F8.4090402@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1433 Darren Reed wrote: > Peter Memishian wrote: >> > What it sounds like to me, is that you're suggesting that rather than >> > utilities automatically use a particular field separator, they should >> > use white space (of some kind) unless they're told to use another >> > character. >> >> Which (again) doesn't work if you need to have empty fields, which is >> quite common (and no, we must not corrupt data by changing empty >> values to >> another token). >> > > An interesting statement given that many text file formats do indeed > have some > sort of token/symbol to indicate "NULL", so it isn't as insurmountable > as is being > suggested. > The point we're trying to make is not that other ways, such as whitespace separator, user selectable separator, etc, are not impossible or unworkable. They are however, more complex and thus more prone to error, while offering no practical advantages to what is being proposed. If you some advantages to an alternative scheme, by all means point them out. > >> > This falls in line with the behaviour of tools like awk, cut, etc. >> >> All of those commands allow a field separator to be specified. > > Yes and that was the purpose of mentioning them - to suggest the idea > that perhaps the field separator should be chosen by the user and if not, > whitespace used. > We're producing output rather than consuming it. I don't see the relevance. > Darren > From jek3@sun.com Thu Jun 12 20:22:07 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D3M7s4024461 for ; Thu, 12 Jun 2008 20:22:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D3M0L4023952; Fri, 13 Jun 2008 11:22:02 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00803TCP5J00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 20:22:01 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00NOETCO5BB0@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 20:22:00 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5D3Lxtp546358; Thu, 12 Jun 2008 20:21:59 -0700 (PDT) Date: Thu, 12 Jun 2008 17:24:43 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851BD64.4060405@sun.com> To: John Leser Cc: Darren Reed , Sebastien Roy , "Garrett D'Amore" , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <4851E87B.9070302@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 3956 John Leser wrote: > Joseph Kowalski wrote: ... > We're proposing a particular way of doing things with the idea that > future CLI tools will do the same thing unless they have a substantial > reason for not doing so. I think the word "guideline" was used to > avoid words like "requirement" which implies all sorts of nasty > process. Sorry if it caused confusion. You are proposing a different way of doing things that flys in the face of so many cases. There have been many cases given the following advice (perhaps in TCR form): "Don't parse complex output. If you need a specific value, provide an option to deliver the specific value" >> 3. "Although one might think that "eval" could be used in the >> shell to >> access the set of values one line at a time, this has major >> pitfalls:" >> >> There are lots of ways to parse in shell. If you are wary of >> eval, >> pick another. The "evil of eval" is not relevant to this case. >> > > I agree that an eval based system could work, but it requires extra > care (as Nicolas has pointed out) in both the production and > consumption of the parseable output, without any advantages I'm aware > of. The "evil of eval" is relevant to explain our choice to not > produce output designed for consumption by a script using "eval", > which is the way dladm currently works. Let's get over eval. It is totally irrelevant. Unfortunately it seems to be detracting from focusing on the actual proposal. >> 4. "Note that this is a change to a Committed interface,..." >> >> I understand the rationale, but I believe this makes the binding >> "Minor:S11", >> not just "Minor". (OK, its a nit,...) >> >> 5. MOST IMPORTANTLY, this utility already provides the "-o" option. >> Why isn't it the best way to write the scripts you are proposing? >> > > Let me see if understand you. I'll use "zoneadm list" as an example > because it's the closest thing to an existing implementation of our > proposal. > > Right now, I do: > > # zoneadm list -p > 0:global:running:/::native:shared > 3:mathesar-tz1:running:/export/home/zones/mathesar-tz1:57e4d1c9-cb85-c882-875e-84f1a50fa95d:native:shared > > > This produces a set of (2) records records. You're suggesting that > with the -o option, this sort of output is not necessary, because I > could just request the specific fields I wanted, one at a time, > without having to worry about field separators, field ordering, etc. > > So I would do something like: > > # zoneadm -z global list -o status > running > > (note this doesn't actually work because zoneadm doesn't support -o) > > I agree that this would be adequate for many purposes, but there are > significant limitations: > > * primary keys: zoneadm allows only zone name as the primary key to > look up data. Lets say my script wants to figure what zone path is > associated with a particular zone uuid. This would require some extra > work. In general, we'd need to anticipate what fields will be needed > as lookup keys and provide a way to do that for our utilities. ???? More importantly, you are a general method for what seems to be a very specific case. > * multiple calls: You have to call the utility once for each field > you want. This can add up if a script wants to iterate over every > zone on the system and there are 100s or 1000s of them. Our proposed > syntax piped into "while read" generally requires only one call. If > the state of the system changes between calls, the script will not get > a coherent set of data from multiple calls. How about a column style output. If you are looking at multiple columns, I just don't buy it. The calls you are worrying about are likely in the noise. ... The more I read, the more I'm convinced that you are designing to the "wierdness" of a couple of utilities and trying to assert that there is some precedent to be found here. - jek3 From gdamore@sun.com Thu Jun 12 20:35:37 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D3ZbW3024649 for ; Thu, 12 Jun 2008 20:35:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5D3ZacS013193 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 20:35:36 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00D05TZCXQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 21:35:36 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00E1LTZB0VA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 21:35:35 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5D3ZZkJ018026 for ; Thu, 12 Jun 2008 20:35:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2D00801TZBHP00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 20:35:35 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2D00H2YTZAB6C0@fe-sfbay-09.sun.com>; Thu, 12 Jun 2008 20:35:35 -0700 (PDT) Date: Thu, 12 Jun 2008 20:34:33 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851E87B.9070302@sun.com> Sender: Garrett.Damore@sun.com To: Joseph Kowalski Cc: John Leser , Darren Reed , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <4851EAC9.90602@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2395 Joseph Kowalski wrote: > John Leser wrote: >> Joseph Kowalski wrote: > ... >> We're proposing a particular way of doing things with the idea that >> future CLI tools will do the same thing unless they have a >> substantial reason for not doing so. I think the word "guideline" >> was used to avoid words like "requirement" which implies all sorts of >> nasty process. Sorry if it caused confusion. > > > You are proposing a different way of doing things that flys in the > face of so many cases. There have been many cases given the following > advice (perhaps in TCR form): > > "Don't parse complex output. If you need a specific value, provide > an option to deliver the specific value" > And therein lies my sort of backhanded comment about XML. I don't understand all the effort being put into making output from these tools "parseable" from whatever scripting language du jour. It seems to me that there are other possibly superior solutions: 1) Add switches to the commands to just query for the data you want (possibly adding switches like -o that someone else mentioned, and possibly adding new switches to indicate a "search key".) This probably works well for some kind of simple data. 2) For data that is more complex, perhaps an XML format isn't that bad of an idea, especially if coupled with the presence of a general purpose tool to parse and extract XML. I think this sounds pretty horrid, but the point here is, the format already exists, tools exist, so why are we inventing a new format? "eval" can't be the rationale here. (And, I'm sure if one doesn't already exist, Roland will figure out how to make the XML parser a ksh93 builtin. :-) 3) Also for complex data --- um, why are we trying to parse it from tools like awk and sh in the first place? I mean, if the main consumer for this kind of data are things like GUI applications such as nwam, why not write those applications in a real language, and provide access to the data in a form that is "natural" to the language -- e.g. structured C data, or hashes in Perl, and so forth? (We do have libdladm, right?) This has the added benefit of separating the data meant to be consumed by application developers from the data used by administrators, and ultimately making the man pages that the admin has to read smaller and hence simpler. :-) -- Garrett From Nicolas.Williams@sun.com Thu Jun 12 20:43:50 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D3hoCQ024745 for ; Thu, 12 Jun 2008 20:43:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5D3hfjQ001020; Fri, 13 Jun 2008 04:43:43 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00907UCT8S00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 20:43:41 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D000XMUCS05A0@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 20:43:40 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5D3haUF019891; Thu, 12 Jun 2008 22:43:36 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5D3haTG019890; Thu, 12 Jun 2008 22:43:36 -0500 (CDT) Date: Thu, 12 Jun 2008 22:43:36 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851BD64.4060405@sun.com> To: John Leser Cc: Joseph Kowalski , Darren Reed , Sebastien Roy , "Garrett D'Amore" , John Plocher , Peter.Memishian@sun.com, psarc-ext Mail-followup-to: John Leser , Joseph Kowalski , Darren Reed , Sebastien Roy , Garrett D'Amore , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <20080613034336.GZ2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1196 On Thu, Jun 12, 2008 at 08:20:52PM -0400, John Leser wrote: > >3. "Although one might think that "eval" could be used in the shell to > > access the set of values one line at a time, this has major pitfalls:" > > > > There are lots of ways to parse in shell. If you are wary of eval, > > pick another. The "evil of eval" is not relevant to this case. > > > > I agree that an eval based system could work, but it requires extra care > (as Nicolas has pointed out) in both the production and consumption of > the parseable output, without any advantages I'm aware of. The "evil of > eval" is relevant to explain our choice to not produce output designed > for consumption by a script using "eval", which is the way dladm > currently works. So, the only quoting that needs to be done is: put all attacker- controlled values (e.g., ESSIDs) in single quotes and quote any single quotes[*] in said values. [*] To quote single quotes in single-quoted strings you need to replace to-be-quoted single quotes with: '"\"\'\"' This works with ksh, ksh93, /bin/sh, /sbin/sh and bash. '"'"' works with ksh, ksh93, /bin/sh, and /sbin/sh, but not with bash. Nico -- From Nicolas.Williams@sun.com Thu Jun 12 20:47:30 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D3lTa4024768 for ; Thu, 12 Jun 2008 20:47:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D3lJNX000164; Fri, 13 Jun 2008 11:47:22 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00E0DUIUWY00@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 21:47:18 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00EKAUIP0PA0@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 21:47:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5D3lDjQ019898; Thu, 12 Jun 2008 22:47:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5D3lDlL019897; Thu, 12 Jun 2008 22:47:13 -0500 (CDT) Date: Thu, 12 Jun 2008 22:47:13 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851EAC9.90602@sun.com> To: "Garrett D'Amore" Cc: Joseph Kowalski , John Leser , Darren Reed , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Mail-followup-to: Garrett D'Amore , Joseph Kowalski , John Leser , Darren Reed , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <20080613034712.GA2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 880 On Thu, Jun 12, 2008 at 08:34:33PM -0700, Garrett D'Amore wrote: > > "Don't parse complex output. If you need a specific value, provide > >an option to deliver the specific value" > > > And therein lies my sort of backhanded comment about XML. I don't > understand all the effort being put into making output from these tools > "parseable" from whatever scripting language du jour. It seems to me > that there are other possibly superior solutions: Shells are *NOT* a "scripting language du jour." The shells have been around for a long time. Shells are not as cool as Perl5, Python, Ruby, whatever. True. All of those have cool libraries with bindings for lots of C APIs. Fine, but the shells won't go away. Shell scripting might be something we want to discourage, but until we decide to do that I don't think we should blow off cases like this one. Nico -- From gdamore@Sun.COM Thu Jun 12 20:59:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D3xGLD025388 for ; Thu, 12 Jun 2008 20:59:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D3x8qi003723 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 11:59:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00A01V2P8200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 20:59:13 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D0007CV2O05C0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 20:59:12 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5D3xCjf025328 for ; Thu, 12 Jun 2008 20:59:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2D00I01URSGB00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 20:59:12 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2D000PKV2N0P80@fe-sfbay-10.sun.com>; Thu, 12 Jun 2008 20:59:11 -0700 (PDT) Date: Thu, 12 Jun 2008 20:58:10 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080613034712.GA2735@Sun.COM> Sender: Garrett.Damore@Sun.COM To: "Garrett D'Amore" , Joseph Kowalski , John Leser , Darren Reed , Sebastien Roy , John Plocher , Peter.Memishian@Sun.COM, psarc-ext Message-id: <4851F052.6070103@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1876 Nicolas Williams wrote: > On Thu, Jun 12, 2008 at 08:34:33PM -0700, Garrett D'Amore wrote: > >>> "Don't parse complex output. If you need a specific value, provide >>> an option to deliver the specific value" >>> >>> >> And therein lies my sort of backhanded comment about XML. I don't >> understand all the effort being put into making output from these tools >> "parseable" from whatever scripting language du jour. It seems to me >> that there are other possibly superior solutions: >> > > Shells are *NOT* a "scripting language du jour." > > The shells have been around for a long time. > > Shells are not as cool as Perl5, Python, Ruby, whatever. True. All of > those have cool libraries with bindings for lots of C APIs. Fine, but > the shells won't go away. > > Shell scripting might be something we want to discourage, but until we > decide to do that I don't think we should blow off cases like this one. > The question isn't about discouraging scripting, but rather, how far do we want to go to enable people to use a shell script to perform something that they really probably should have a better tool for? I get the feeling that we're trying to represent what is really structured data, to a language that doesn't have even the slightest concept of data structures. Given that this is the case, how useful is the ability to process this data in some kind of tabular format? And, maybe what we need to do is provide structured 'access' via some kind of helper commands (or those -o switches that we've talked about). Yeah, it might be another fork/exec combination compared to parsing it natively with eval, but I suspect the benefits of structured access (and reduced bugs!) make up for the minor performance difference. (And if performance is an issue, then maybe shell really is the wrong tool!) -- Garrett From Darren.Reed@sun.com Thu Jun 12 21:10:06 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D4A5X0026035 for ; Thu, 12 Jun 2008 21:10:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D49sEe006994 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 12:10:04 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00D0DVKQMW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 21:10:02 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D0023OVKOSFC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 21:10:01 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5D4AOmM022608 for ; Fri, 13 Jun 2008 04:10:24 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K2D00701VFDS200@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 12:09:38 +0800 (SGT) Received: from [10.0.232.239] ([192.18.41.196]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K2D00MFRVJZ9MS7@mail-apac.sun.com>; Fri, 13 Jun 2008 12:09:38 +0800 (SGT) Date: Thu, 12 Jun 2008 21:09:52 -0700 From: Darren Reed Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851F052.6070103@sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore" Cc: Joseph Kowalski , John Leser , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <4851F310.5070109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <4851F052.6070103@sun.com> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) Status: RO Content-Length: 700 Garrett D'Amore wrote: ... > And, maybe what we need to do is provide structured 'access' via some > kind of helper commands (or those -o switches that we've talked > about). Yeah, it might be another fork/exec combination compared to > parsing it natively with eval, but I suspect the benefits of > structured access (and reduced bugs!) make up for the minor > performance difference. (And if performance is an issue, then maybe > shell really is the wrong tool!) Hmm, are you suggesting that there should be an output mode that is complex, such as XML, and that we feed said XML into something else, whereupon we describe how we want the XML decoded and then presented as output? Darren From Nicolas.Williams@sun.com Thu Jun 12 21:15:22 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D4FLIi026525 for ; Thu, 12 Jun 2008 21:15:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5D4FGQN013659; Thu, 12 Jun 2008 21:15:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00H0PVTHCS00@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 22:15:17 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00EYUVTF11B0@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 22:15:16 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5D4FFEQ019918; Thu, 12 Jun 2008 23:15:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5D4FF0X019917; Thu, 12 Jun 2008 23:15:15 -0500 (CDT) Date: Thu, 12 Jun 2008 23:15:15 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851F052.6070103@sun.com> To: "Garrett D'Amore" Cc: Joseph Kowalski , John Leser , Darren Reed , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Mail-followup-to: Garrett D'Amore , Joseph Kowalski , John Leser , Darren Reed , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <20080613041515.GC2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <4851F052.6070103@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2060 On Thu, Jun 12, 2008 at 08:58:10PM -0700, Garrett D'Amore wrote: > The question isn't about discouraging scripting, but rather, how far do > we want to go to enable people to use a shell script to perform > something that they really probably should have a better tool for? Fair enough. But then, network configuration has a long history of being scripted around. I could conceivably agree that some areas of the system should not be scripted with shells, say. But this one strikes me as not such an area of the system. > I get the feeling that we're trying to represent what is really > structured data, to a language that doesn't have even the slightest > concept of data structures. You're inviting Roland to comment :) > Given that this is the case, how useful is the ability to process this > data in some kind of tabular format? Well, I'm not in love with the tabular format myself. I think the existing variable=quoted-value scheme is slightly flawed, namely in that the quoting scheme is deficient. It's also imperfect in that some shells execute loop bodies in pipes in sub-shells, but this is still useful. > And, maybe what we need to do is provide structured 'access' via some > kind of helper commands (or those -o switches that we've talked about). Yes, that's fine too: first use dladm to list links, then per-link, per-prop to query properties. This requires lots of fork()/exec()s, but, sure -- ksh93 fans can always add plugins to speed things up. > Yeah, it might be another fork/exec combination compared to parsing it > natively with eval, but I suspect the benefits of structured access (and > reduced bugs!) make up for the minor performance difference. (And if > performance is an issue, then maybe shell really is the wrong tool!) Maybe, but I don't think dladm's output is so structured. (And one might argue that with ksh93 as our preferred shell then maybe we should have options to output ksh93 compound variable syntax, which would address most of your comments on structured data. Roland?) Nico -- From Nicolas.Williams@sun.com Thu Jun 12 21:16:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D4GPKa026694 for ; Thu, 12 Jun 2008 21:16:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5D4GFT1011194; Fri, 13 Jun 2008 05:16:19 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00E01VV5BY00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 21:16:17 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D002LEVV5SHA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 21:16:17 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5D4GGB3019925; Thu, 12 Jun 2008 23:16:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5D4GGYK019924; Thu, 12 Jun 2008 23:16:16 -0500 (CDT) Date: Thu, 12 Jun 2008 23:16:16 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851F310.5070109@Sun.COM> To: Darren Reed Cc: "Garrett D'Amore" , Joseph Kowalski , John Leser , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Mail-followup-to: Darren Reed , Garrett D'Amore , Joseph Kowalski , John Leser , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <20080613041616.GD2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <4851F052.6070103@sun.com> <4851F310.5070109@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 911 On Thu, Jun 12, 2008 at 09:09:52PM -0700, Darren Reed wrote: > Garrett D'Amore wrote: > ... > >And, maybe what we need to do is provide structured 'access' via some > >kind of helper commands (or those -o switches that we've talked > >about). Yeah, it might be another fork/exec combination compared to > >parsing it natively with eval, but I suspect the benefits of > >structured access (and reduced bugs!) make up for the minor > >performance difference. (And if performance is an issue, then maybe > >shell really is the wrong tool!) > > Hmm, are you suggesting that there should be an output mode that is complex, > such as XML, and that we feed said XML into something else, whereupon we > describe how we want the XML decoded and then presented as output? No, Garret is suggesting that scripts get one item at a time from dladm, incurring many more fork()/exec()s, but otherwise not too shabby. From gdamore@sun.com Thu Jun 12 21:34:42 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D4YgXo027741 for ; Thu, 12 Jun 2008 21:34:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5D4Ygpx038664 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Jun 2008 22:34:42 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00I09WPUD500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 22:34:42 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00EUNWPL13D0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 22:34:33 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5D4YXLQ019299 for ; Thu, 12 Jun 2008 21:34:33 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2D00901WJ4TF00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 21:34:33 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2D000WTWPK0PD0@fe-sfbay-10.sun.com>; Thu, 12 Jun 2008 21:34:32 -0700 (PDT) Date: Thu, 12 Jun 2008 21:33:31 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851F310.5070109@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: Joseph Kowalski , John Leser , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <4851F89B.8090205@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <4851F052.6070103@sun.com> <4851F310.5070109@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1163 Darren Reed wrote: > Garrett D'Amore wrote: > ... >> And, maybe what we need to do is provide structured 'access' via some >> kind of helper commands (or those -o switches that we've talked >> about). Yeah, it might be another fork/exec combination compared to >> parsing it natively with eval, but I suspect the benefits of >> structured access (and reduced bugs!) make up for the minor >> performance difference. (And if performance is an issue, then maybe >> shell really is the wrong tool!) > > Hmm, are you suggesting that there should be an output mode that is > complex, > such as XML, and that we feed said XML into something else, whereupon we > describe how we want the XML decoded and then presented as output? Well, that's one possible interepretation. But what I had more in mind was something like: cat myxmloutput hme0 255.255.255.0 hme0_netmask = `cat myxmloutput | xml_query -p interface:name=hme0 -o interface:netmask` Yes, its fairly hideous. But it allows a single common parser to be used, that is not bound the limitations of the shell. -- Garrett > > Darren > From peter.memishian@sun.com Thu Jun 12 21:58:49 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D4wmoT028420 for ; Thu, 12 Jun 2008 21:58:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5D4wkYD044004; Thu, 12 Jun 2008 22:58:47 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00J0VXTZQ000@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 22:58:47 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00EXVXTV19B0@brm-avmta-1.central.sun.com>; Thu, 12 Jun 2008 22:58:44 -0600 (MDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5D4weMv019977; Fri, 13 Jun 2008 00:58:40 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5D4wehQ687247; Fri, 13 Jun 2008 00:58:40 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5D4weIU687226; Fri, 13 Jun 2008 00:58:40 -0400 (EDT) Date: Fri, 13 Jun 2008 00:58:40 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851F052.6070103@sun.com> To: "Garrett D'Amore" Cc: Joseph Kowalski , John Leser , Darren Reed , Sebastien Roy , John Plocher , peter.memishian@sun.com, psarc-ext Reply-to: peter.memishian@sun.com Message-id: <18513.65152.38435.137573@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <4851F052.6070103@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 701 > The question isn't about discouraging scripting, but rather, how far do > we want to go to enable people to use a shell script to perform > something that they really probably should have a better tool for? Folks, people *are* scripting using our utilities. If someone wants to go off and design an alternative universe, great, please write up your case and submit it -- I'm sure you'll be able to fix some hard problems along the way. In the meantime, dladm(1M) *already* has a parseable output mode, and that output mode is problematic. This case is about fixing that, along with providing a point of reference that others in similar situations could make use of here and now. -- meem From dan.mick@sun.com Thu Jun 12 22:19:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D5JXcf028550 for ; Thu, 12 Jun 2008 22:19:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D5JOC8024872; Fri, 13 Jun 2008 13:19:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2D00E03YSF9T00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 22:19:27 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2D00BAAYSE4R30@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 22:19:27 -0700 (PDT) Received: from [129.150.16.135] (vpn-129-150-16-135.SFBay.Sun.COM [129.150.16.135]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5D5JOoa011304; Thu, 12 Jun 2008 22:19:24 -0700 (PDT) Date: Thu, 12 Jun 2008 22:19:19 -0700 From: Dan Mick Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080613034712.GA2735@Sun.COM> To: "Garrett D'Amore" , Joseph Kowalski , John Leser , Darren Reed , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <48520357.4030006@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) Status: RO Content-Length: 1102 Nicolas Williams wrote: > On Thu, Jun 12, 2008 at 08:34:33PM -0700, Garrett D'Amore wrote: >>> "Don't parse complex output. If you need a specific value, provide >>> an option to deliver the specific value" >>> >> And therein lies my sort of backhanded comment about XML. I don't >> understand all the effort being put into making output from these tools >> "parseable" from whatever scripting language du jour. It seems to me >> that there are other possibly superior solutions: > > Shells are *NOT* a "scripting language du jour." > > The shells have been around for a long time. > > Shells are not as cool as Perl5, Python, Ruby, whatever. True. All of > those have cool libraries with bindings for lots of C APIs. Fine, but > the shells won't go away. > > Shell scripting might be something we want to discourage, but until we > decide to do that I don't think we should blow off cases like this one. and interactive use of shell is probably going to stick around for a while, and I don't know about all of you, but I write a whole lot of interactive shell pipelines in a day. From jek3@Sun.COM Thu Jun 12 23:20:25 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D6KONo029155 for ; Thu, 12 Jun 2008 23:20:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D6K3h8013969; Fri, 13 Jun 2008 14:20:20 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E001031LSHS00@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 00:20:16 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E000OQ1LS9D00@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 00:20:16 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5D6KF7f560889; Thu, 12 Jun 2008 23:20:15 -0700 (PDT) Date: Thu, 12 Jun 2008 20:22:59 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851EAC9.90602@sun.com> To: "Garrett D'Amore" Cc: John Leser , Darren Reed , Sebastien Roy , John Plocher , Peter.Memishian@Sun.COM, psarc-ext Message-id: <48521243.2060002@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <4850937E.2040504@Sun.COM> <18512.38733.448019.247611@gargle.gargle.HOWL> <48509E61.1010500@Sun.COM> <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 814 Garrett D'Amore wrote: > 3) Also for complex data --- um, why are we trying to parse it from > tools like awk and sh in the first place? I mean, if the main > consumer for this kind of data are things like GUI applications such > as nwam, why not write those applications in a real language, and > provide access to the data in a form that is "natural" to the > language -- e.g. structured C data, or hashes in Perl, and so > forth? (We do have libdladm, right?) This has the added benefit of > separating the data meant to be consumed by application developers > from the data used by administrators, and ultimately making the man > pages that the admin has to read smaller and hence simpler. :-) libdladm.so ? Not the worst idea I've heard, but I doubt resources would be allocated. - jek3 From Darren.Reed@sun.com Thu Jun 12 23:22:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D6MmZD029187 for ; Thu, 12 Jun 2008 23:22:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5D6MdCr017817 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 07:22:47 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E0010D1PXOB00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 00:22:45 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E000TC1PW9600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 00:22:45 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5D6Nc54015214 for ; Fri, 13 Jun 2008 06:23:38 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K2E005011CXG800@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 14:21:02 +0800 (SGT) Received: from [10.0.232.239] ([192.18.41.196]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K2E00FVO1MZQY9C@mail-apac.sun.com>; Fri, 13 Jun 2008 14:21:02 +0800 (SGT) Date: Thu, 12 Jun 2008 23:22:35 -0700 From: Darren Reed Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48520357.4030006@sun.com> Sender: Darren.Reed@sun.com To: Dan Mick Cc: "Garrett D'Amore" , Joseph Kowalski , John Leser , Sebastien Roy , John Plocher , peter.memishian@sun.com, psarc-ext Message-id: <4852122B.9020409@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) Status: RO Content-Length: 1456 Dan Mick wrote: > ... > and interactive use of shell is probably going to stick around for a > while, and I don't know about all of you, but I write a whole lot of > interactive shell pipelines in a day. And indeed I think a lot of us fit into that category. So, that got us a lot off track... To bring this back to where it started, the issues are (for PSARC): - given that there will be future work that wants to generate parsable output, do we need an opinion written up (for this case) to serve as the notice of our decision about it or is it sufficient to just cite this case? - if we're going to use this case as the foundation for all future cases that are presenting output from commands, such as these, that is meant to be parsable, do we: 1) decide that we insist that commands use -o/-p unless history prevents it? (i.e. new commands *MUST* use this combination) and 2) decide that | is our field separator or do we decide on another? (":" is already used but "," would make output immediately consumable by things that work on .csv files.) I'm not concerned about introducing something different, it is more important for what is introduced to make sense and work easily. or 3) have fun discussing this now, let this case do whatever and spend a whole bunch of time discussing it with some future case and let people rewhack their commands at some later date? Darren From jek3@sun.com Thu Jun 12 23:23:43 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D6Nhkp029201 for ; Thu, 12 Jun 2008 23:23:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5D6NefB010135; Thu, 12 Jun 2008 23:23:40 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00H051RGH700@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 23:23:40 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00BUU1RF4V70@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 23:23:39 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5D6Nc13561239; Thu, 12 Jun 2008 23:23:38 -0700 (PDT) Date: Thu, 12 Jun 2008 20:26:23 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4851F052.6070103@sun.com> To: "Garrett D'Amore" Cc: John Leser , Darren Reed , Sebastien Roy , John Plocher , peter.memishian@sun.com, psarc-ext Message-id: <4852130F.1040009@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <4851F052.6070103@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 437 Garrett D'Amore wrote: > The question isn't about discouraging scripting, but rather, how far > do we want to go to enable people to use a shell script to perform > something that they really probably should have a better tool for? I think "to shell or not to shell" isn't a question anywhere close to the bounds of this case. I'd love to see a proposal aimed at improving this situation, bit for now, its shells. Focus. - jek3 From jek3@sun.com Thu Jun 12 23:37:29 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D6bS2Y029240 for ; Thu, 12 Jun 2008 23:37:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5D6bM9m022512; Fri, 13 Jun 2008 07:37:22 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E007032E9SV00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 23:37:21 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E005A52E92H30@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 23:37:21 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5D6bK7n562264; Thu, 12 Jun 2008 23:37:20 -0700 (PDT) Date: Thu, 12 Jun 2008 20:40:04 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852122B.9020409@Sun.COM> To: Darren Reed Cc: Dan Mick , "Garrett D'Amore" , John Leser , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <48521644.5040403@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 2056 Darren Reed wrote: > Dan Mick wrote: >> ... >> and interactive use of shell is probably going to stick around for a >> while, and I don't know about all of you, but I write a whole lot of >> interactive shell pipelines in a day. > > And indeed I think a lot of us fit into that category. > > So, that got us a lot off track... > > To bring this back to where it started, the issues are (for PSARC): > - given that there will be future work that wants to generate > parsable output, do we need an opinion written up (for this case) > to serve as the notice of our decision about it or is it sufficient > to just cite this case? The bottom line is that we've written a few "kitchen sink" utilities. That's the first less than ideal thing that we did. Given where we are, I'm not inclined to approve this case as anything else than a "one off". > - if we're going to use this case as the foundation for all future > cases that are presenting output from commands, such as these, > that is meant to be parsable, do we: > 1) decide that we insist that commands use -o/-p unless history > prevents it? (i.e. new commands *MUST* use this combination) > > and > > 2) decide that | is our field separator or do we decide on another? > (":" is already used but "," would make output immediately > consumable by things that work on .csv files.) I'm not concerned > about introducing something different, it is more important for > what is introduced to make sense and work easily. > > or or, you could construct an abstract case to define a "preferred, other than white space, separator". This almost has to be done as a revision to the clip specification (IMHO), > 3) have fun discussing this now, let this case do whatever and > spend a whole bunch of time discussing it with some future case > and let people rewhack their commands at some later date? I guess that I want, but I would phrase this as "we can take a random stick in the mud, and live with our incompletely investigated decision". - jek3 From peter.memishian@sun.com Thu Jun 12 23:51:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D6pFNC029464 for ; Thu, 12 Jun 2008 23:51:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D6oTU4023744; Fri, 13 Jun 2008 14:51:11 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E0040H31A1Q00@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 00:51:10 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E000A13199620@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 00:51:09 -0600 (MDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5D6p5RI036446; Fri, 13 Jun 2008 02:51:05 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5D6p5S4600237; Fri, 13 Jun 2008 02:51:05 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5D6p5UK600210; Fri, 13 Jun 2008 02:51:05 -0400 (EDT) Date: Fri, 13 Jun 2008 02:51:05 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48521644.5040403@sun.com> To: Joseph Kowalski Cc: Darren Reed , Dan Mick , "Garrett D'Amore" , John Leser , Sebastien Roy , John Plocher , peter.memishian@sun.com, psarc-ext Reply-to: peter.memishian@sun.com Message-id: <18514.6361.177137.678731@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 980 > > To bring this back to where it started, the issues are (for PSARC): > > - given that there will be future work that wants to generate > > parsable output, do we need an opinion written up (for this case) > > to serve as the notice of our decision about it or is it sufficient > > to just cite this case? > > The bottom line is that we've written a few "kitchen sink" utilities. > That's the first less than ideal thing that we did. Given where we > are, I'm not inclined to approve this case as anything else than a > "one off". As per the subject line, we're really only looking for approval with dladm. As per the case "Overview" section, we (Solaris Networking) intend to follow the dladm approach with future networking CLIs -- but each of those will have their own case and stand on their own. That said, I don't see an issue with gently encouraging others who may be inventing a new parseable CLI to follow the simple approach outlined here. -- meem From Darren.Reed@sun.com Fri Jun 13 00:07:52 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D77po7000529 for ; Fri, 13 Jun 2008 00:07:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D77nPQ029572 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 15:07:50 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00B013T1BI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 00:07:49 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E005003T02H90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 00:07:49 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5D78BDP007407 for ; Fri, 13 Jun 2008 07:08:11 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K2E002013ECTE00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 15:06:04 +0800 (SGT) Received: from [10.0.232.239] ([192.18.41.196]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K2E00FUI3Q0QYFC@mail-apac.sun.com>; Fri, 13 Jun 2008 15:06:04 +0800 (SGT) Date: Fri, 13 Jun 2008 00:07:38 -0700 From: Darren Reed Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18514.6361.177137.678731@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: Peter.Memishian@sun.com Cc: Joseph Kowalski , Dan Mick , "Garrett D'Amore" , John Leser , Sebastien Roy , John Plocher , psarc-ext Message-id: <48521CBA.1030400@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) Status: RO Content-Length: 1563 Peter Memishian wrote: > > > To bring this back to where it started, the issues are (for PSARC): > > > - given that there will be future work that wants to generate > > > parsable output, do we need an opinion written up (for this case) > > > to serve as the notice of our decision about it or is it sufficient > > > to just cite this case? > > > > The bottom line is that we've written a few "kitchen sink" utilities. > > That's the first less than ideal thing that we did. Given where we > > are, I'm not inclined to approve this case as anything else than a > > "one off". > > As per the subject line, we're really only looking for approval with > dladm. As per the case "Overview" section, we (Solaris Networking) intend > to follow the dladm approach with future networking CLIs -- but each of > those will have their own case and stand on their own. I think you mean to say "we (this case)" or "we (this project)", didn't you? If this case is only being targetted at dladm then it has no binding on what anyone else is doing, be it in Solaris Networking, or the OpenSolaris networking community or any other project. > That said, I don't > see an issue with gently encouraging others who may be inventing a new > parseable CLI to follow the simple approach outlined here. > To encourage others to follow this case "just because it seems simple" doesn't bode well. What happens when someone has output that has |'s in it and decides to use ";" as their separator? (Similar to how this case appears to prefer "|" over ":".) Darren From peter.memishian@sun.com Fri Jun 13 00:16:58 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D7GvDl000600 for ; Fri, 13 Jun 2008 00:16:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5D7GtP8010196; Fri, 13 Jun 2008 01:16:56 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00J01487YX00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 00:16:55 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00B914854PC0@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 00:16:54 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5D7Goc9041301; Fri, 13 Jun 2008 03:16:50 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5D7Gokr851514; Fri, 13 Jun 2008 03:16:50 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5D7GoiB851491; Fri, 13 Jun 2008 03:16:50 -0400 (EDT) Date: Fri, 13 Jun 2008 03:16:49 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48521CBA.1030400@Sun.COM> To: Darren Reed Cc: peter.memishian@sun.com, Joseph Kowalski , Dan Mick , "Garrett D'Amore" , John Leser , Sebastien Roy , John Plocher , psarc-ext Reply-to: peter.memishian@sun.com Message-id: <18514.7905.990388.114601@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1297 > > > The bottom line is that we've written a few "kitchen sink" utilities. > > > That's the first less than ideal thing that we did. Given where we > > > are, I'm not inclined to approve this case as anything else than a > > > "one off". > > > > As per the subject line, we're really only looking for approval with > > dladm. As per the case "Overview" section, we (Solaris Networking) intend > > to follow the dladm approach with future networking CLIs -- but each of > > those will have their own case and stand on their own. > > I think you mean to say "we (this case)" or "we (this project)", didn't you? We as in "John and I", the submitters of the case. > To encourage others to follow this case "just because it seems simple" > doesn't bode well. What happens when someone has output that has > |'s in it and decides to use ";" as their separator? (Similar to how this > case appears to prefer "|" over ":".) Huh? The conclusion was already reached that the choice of separator is immaterial since it will be quoted anyway. Pursuant to that, John and I agreed to use ":" because it already has precedent with zoneadm(1M) (and has been a Unix separator character in other contexts such as /etc files since the dawn of time). Is this horse dead yet? -- meem From gdamore@sun.com Fri Jun 13 00:19:50 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D7JncX000614 for ; Fri, 13 Jun 2008 00:19:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5D7JXcD003787 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 15:19:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00K094CY3300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 00:19:46 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00BQR4CX4NB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 00:19:45 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5D7JjZT001304 for ; Fri, 13 Jun 2008 00:19:45 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00E0147RXT00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 00:19:45 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E00H1Y4CWW680@fe-sfbay-10.sun.com>; Fri, 13 Jun 2008 00:19:45 -0700 (PDT) Date: Fri, 13 Jun 2008 00:18:41 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48521644.5040403@sun.com> Sender: Garrett.Damore@sun.com To: Joseph Kowalski Cc: Darren Reed , Dan Mick , John Leser , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <48521F51.2040401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1651 Joseph Kowalski wrote: > Darren Reed wrote: >> Dan Mick wrote: >>> ... >>> and interactive use of shell is probably going to stick around for a >>> while, and I don't know about all of you, but I write a whole lot of >>> interactive shell pipelines in a day. >> >> And indeed I think a lot of us fit into that category. >> >> So, that got us a lot off track... >> >> To bring this back to where it started, the issues are (for PSARC): >> - given that there will be future work that wants to generate >> parsable output, do we need an opinion written up (for this case) >> to serve as the notice of our decision about it or is it sufficient >> to just cite this case? > > The bottom line is that we've written a few "kitchen sink" utilities. > That's the first less than ideal thing that we did. Given where we > are, I'm not inclined to approve this case as anything else than a > "one off". I'm happy with this as a one off. The whole other side track was mostly in argument to "lets invent a new syntax for all commands to output". And I honestly don't care what the delimiter we pick is: any output format we conceive is going to be either better or worse for at least some interpreted language out there. My one sort of pseudo-general question here is, what are the consumers for this dladm output? Are there are any in particular that we know of that need the parseable output, or are we just perceiving that they might be useful to some admin somewhere? ('Cause I gotta tell you, I have a hard time thinking of any day-in-day out sort of scripting scenario where the ESSID is likely to be useful to have.) -- Garrett From peter.memishian@sun.com Fri Jun 13 00:35:39 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D7Zc5e000889 for ; Fri, 13 Jun 2008 00:35:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5D7ZY6I014724; Fri, 13 Jun 2008 01:35:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00L0D53D1T00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 00:35:37 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00BP753C4PD0@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 00:35:37 -0700 (PDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5D7ZVsX038545; Fri, 13 Jun 2008 03:35:31 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5D7ZVWj067514; Fri, 13 Jun 2008 03:35:31 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5D7ZVrK067482; Fri, 13 Jun 2008 03:35:31 -0400 (EDT) Date: Fri, 13 Jun 2008 03:35:31 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48521F51.2040401@sun.com> To: "Garrett D'Amore" Cc: Joseph Kowalski , Darren Reed , Dan Mick , John Leser , Sebastien Roy , John Plocher , peter.memishian@sun.com, psarc-ext Reply-to: peter.memishian@sun.com Message-id: <18514.9027.347913.48202@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <48521F51.2040401@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 383 > My one sort of pseudo-general question here is, what are the consumers > for this dladm output? Numerous test suites need parseable dladm output. Also, VirtualBox, virt-manager, and some GNOME utilities consume dladm output, among others. This case has suffered enough; I'm praying we don't now rathole into a long thread on the need for a parseable output mode. -- meem From Darren.Moffat@sun.com Fri Jun 13 01:55:55 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5D8tsfj003711 for ; Fri, 13 Jun 2008 01:55:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5D8ts30015528 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 01:55:54 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E0000D8T4EW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 01:55:52 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00F458T25B70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 01:55:51 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5D8toeW028782 for ; Fri, 13 Jun 2008 08:55:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00J018AAAO00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 09:55:50 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E00GRM8SYEG20@fe-emea-10.sun.com>; Fri, 13 Jun 2008 09:55:48 +0100 (BST) Date: Fri, 13 Jun 2008 09:55:46 +0100 From: Darren J Moffat Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <48521F51.2040401@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Joseph Kowalski , John Leser , Dan Mick , psarc-ext , Sebastien Roy , John Plocher , Darren Reed , Peter.Memishian@sun.com Message-id: <48523612.1090903@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <48521F51.2040401@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 778 Garrett D'Amore wrote: > My one sort of pseudo-general question here is, what are the consumers > for this dladm output? Are there are any in particular that we know of > that need the parseable output, or are we just perceiving that they > might be useful to some admin somewhere? ('Cause I gotta tell you, I > have a hard time thinking of any day-in-day out sort of scripting I can think of plenty, but the top of my list example is using the ESSID of an active link to switch which ipfilter ruleset I activate. For example if I know I'm at home because the ESSID says I am I might have some things open that I wouldn't I've I'm on some previously unknown open public network, then if I'm on sunwifi I might do something different again. -- Darren J Moffat From John.Leser@sun.com Fri Jun 13 08:23:51 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DFNoVV010936 for ; Fri, 13 Jun 2008 08:23:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DFNeSQ025283 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 16:23:50 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00H03QROUC00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 09:23:48 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E006TFQRNDKC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 09:23:47 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5DFNlGe021870 for ; Fri, 13 Jun 2008 15:23:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00D01P37KV00@mail-amer.sun.com> (original mail from John.Leser@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 09:23:47 -0600 (MDT) Received: from gir.East.Sun.COM ([129.148.174.24]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E00M3LQRB12F0@mail-amer.sun.com>; Fri, 13 Jun 2008 09:23:36 -0600 (MDT) Date: Fri, 13 Jun 2008 11:25:10 -0400 From: John Leser Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18514.9027.347913.48202@gargle.gargle.HOWL> Sender: John.Leser@sun.com To: Peter.Memishian@sun.com Cc: "Garrett D'Amore" , Joseph Kowalski , Darren Reed , Dan Mick , Sebastien Roy , John Plocher , psarc-ext Reply-to: John.Leser@sun.com Message-id: <48529156.4080207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <48521F51.2040401@sun.com> <18514.9027.347913.48202@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 629 Peter Memishian wrote: > > My one sort of pseudo-general question here is, what are the consumers > > for this dladm output? > > Numerous test suites need parseable dladm output. Also, VirtualBox, > virt-manager, and some GNOME utilities consume dladm output, among others. > I will second the idea that this sort of output is *very* helpful for test development. Ksh seems to be the environment of choice for test development, especially for things like setup/cleanup scripts. -John > This case has suffered enough; I'm praying we don't now rathole into a > long thread on the need for a parseable output mode. > From gdamore@sun.com Fri Jun 13 08:28:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DFSNZN011196 for ; Fri, 13 Jun 2008 08:28:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DFSIwa027412 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 16:28:22 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00J01QZAQM00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 08:28:22 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00G3UQZ97M20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 08:28:21 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5DFSLG7020388 for ; Fri, 13 Jun 2008 08:28:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00E01Q9SCV00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 08:28:21 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E00BOHQZ60AE0@fe-sfbay-09.sun.com>; Fri, 13 Jun 2008 08:28:19 -0700 (PDT) Date: Fri, 13 Jun 2008 08:27:14 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18514.9027.347913.48202@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: Peter.Memishian@sun.com Cc: Joseph Kowalski , Darren Reed , Dan Mick , John Leser , Sebastien Roy , John Plocher , psarc-ext Message-id: <485291D2.6030802@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <48521F51.2040401@sun.com> <18514.9027.347913.48202@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 583 Peter Memishian wrote: > > My one sort of pseudo-general question here is, what are the consumers > > for this dladm output? > > Numerous test suites need parseable dladm output. Also, VirtualBox, > virt-manager, and some GNOME utilities consume dladm output, among others. > > This case has suffered enough; I'm praying we don't now rathole into a > long thread on the need for a parseable output mode. > No, its fine. I'm sorry I opened my yap in the first place. (The question was one of curiosity, not one that was intended to drive architecture.) -- Garrett From Nicolas.Williams@sun.com Fri Jun 13 08:37:46 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DFbkZ5011394 for ; Fri, 13 Jun 2008 08:37:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DFbehc017438; Fri, 13 Jun 2008 09:37:42 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00I1JRETRQ00@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 09:37:41 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E006HVRESDKE0@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 09:37:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5DFbesX020094; Fri, 13 Jun 2008 10:37:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5DFbelX020093; Fri, 13 Jun 2008 10:37:40 -0500 (CDT) Date: Fri, 13 Jun 2008 10:37:40 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852122B.9020409@Sun.COM> To: Darren Reed Cc: Dan Mick , "Garrett D'Amore" , Joseph Kowalski , John Leser , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Mail-followup-to: Darren Reed , Dan Mick , Garrett D'Amore , Joseph Kowalski , John Leser , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <20080613153739.GE2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1410 On Thu, Jun 12, 2008 at 11:22:35PM -0700, Darren Reed wrote: > To bring this back to where it started, the issues are (for PSARC): > - given that there will be future work that wants to generate > parsable output, do we need an opinion written up (for this case) > to serve as the notice of our decision about it or is it sufficient > to just cite this case? > > - if we're going to use this case as the foundation for all future > cases that are presenting output from commands, such as these, > that is meant to be parsable, do we: > 1) decide that we insist that commands use -o/-p unless history > prevents it? (i.e. new commands *MUST* use this combination) Maybe. > and > > 2) decide that | is our field separator or do we decide on another? > (":" is already used but "," would make output immediately > consumable by things that work on .csv files.) I'm not concerned > about introducing something different, it is more important for > what is introduced to make sense and work easily. One big issue I have with this tabular output approach is that I don't know how to then unescape the escaped separator characters in the field values. > 3) have fun discussing this now, let this case do whatever and > spend a whole bunch of time discussing it with some future case > and let people rewhack their commands at some later date? 4) Fully bake this case. From Nicolas.Williams@sun.com Fri Jun 13 08:38:52 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DFcqs0011414 for ; Fri, 13 Jun 2008 08:38:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DFclrg011228; Fri, 13 Jun 2008 08:38:48 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00I07RGNTI00@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 09:38:47 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E006UDRGMDKE0@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 09:38:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5DFckKX020101; Fri, 13 Jun 2008 10:38:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5DFckpr020100; Fri, 13 Jun 2008 10:38:46 -0500 (CDT) Date: Fri, 13 Jun 2008 10:38:45 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18514.7905.990388.114601@gargle.gargle.HOWL> To: Peter Memishian Cc: Darren Reed , Joseph Kowalski , Dan Mick , "Garrett D'Amore" , John Leser , Sebastien Roy , John Plocher , psarc-ext Mail-followup-to: Peter Memishian , Darren Reed , Joseph Kowalski , Dan Mick , Garrett D'Amore , John Leser , Sebastien Roy , John Plocher , psarc-ext Message-id: <20080613153845.GF2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 482 On Fri, Jun 13, 2008 at 03:16:49AM -0400, Peter Memishian wrote: > Is this horse dead yet? No > Huh? The conclusion was already reached that the choice of separator is > immaterial since it will be quoted anyway. Pursuant to that, John and I > agreed to use ":" because it already has precedent with zoneadm(1M) (and > has been a Unix separator character in other contexts such as /etc files > since the dawn of time). How should scripts unescape escaped separators? Nico -- From John.Leser@Sun.COM Fri Jun 13 08:42:19 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DFgJ6Q011485 for ; Fri, 13 Jun 2008 08:42:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DFfplN012441 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 08:42:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00J0RRMG3P00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 09:42:16 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E006JNRMFDKG0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 09:42:15 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5DFgFiv016187 for ; Fri, 13 Jun 2008 15:42:15 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00501QVMAY00@mail-amer.sun.com> (original mail from John.Leser@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 09:42:15 -0600 (MDT) Received: from gir.East.Sun.COM ([129.148.174.24]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E00BJ4RMAX1A0@mail-amer.sun.com>; Fri, 13 Jun 2008 09:42:11 -0600 (MDT) Date: Fri, 13 Jun 2008 11:43:45 -0400 From: John Leser Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080613153845.GF2735@Sun.COM> Sender: John.Leser@Sun.COM To: Peter Memishian , Darren Reed , Joseph Kowalski , Dan Mick , "Garrett D'Amore" , John Leser , Sebastien Roy , John Plocher , psarc-ext Reply-to: John.Leser@Sun.COM Message-id: <485295B1.9010407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> <20080613153845.GF2735@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 633 Nicolas Williams wrote: > On Fri, Jun 13, 2008 at 03:16:49AM -0400, Peter Memishian wrote: >> Is this horse dead yet? > > No > >> Huh? The conclusion was already reached that the choice of separator is >> immaterial since it will be quoted anyway. Pursuant to that, John and I >> agreed to use ":" because it already has precedent with zoneadm(1M) (and >> has been a Unix separator character in other contexts such as /etc files >> since the dawn of time). > > How should scripts unescape escaped separators? The "read" command handles this for you if you set IFS correctly (and the escape character is \). -John > > Nico From Michael.Schuster@sun.com Fri Jun 13 08:49:25 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DFnOpJ011654 for ; Fri, 13 Jun 2008 08:49:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DFnJ8c022579 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 09:49:24 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00I05RYBWP00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 08:49:23 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00CZ1RYBNXC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 08:49:23 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5DFnMXp023039 for ; Fri, 13 Jun 2008 08:49:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00I01RR6T200@fe-sfbay-10.sun.com> (original mail from Michael.Schuster@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 08:49:22 -0700 (PDT) Received: from [192.168.2.10] ([75.36.155.121]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E00596RY39HC0@fe-sfbay-10.sun.com>; Fri, 13 Jun 2008 08:49:15 -0700 (PDT) Date: Fri, 13 Jun 2008 08:49:18 -0700 From: Michael Schuster Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <485295B1.9010407@Sun.COM> Sender: Michael.Schuster@sun.com To: John.Leser@sun.com Cc: Peter Memishian , Darren Reed , Joseph Kowalski , Dan Mick , "Garrett D'Amore" , Sebastien Roy , John Plocher , psarc-ext Message-id: <485296FE.1060302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> <20080613153845.GF2735@Sun.COM> <485295B1.9010407@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 941 John Leser wrote: > Nicolas Williams wrote: >> On Fri, Jun 13, 2008 at 03:16:49AM -0400, Peter Memishian wrote: >>> Is this horse dead yet? >> >> No >> >>> Huh? The conclusion was already reached that the choice of separator is >>> immaterial since it will be quoted anyway. Pursuant to that, John and I >>> agreed to use ":" because it already has precedent with zoneadm(1M) (and >>> has been a Unix separator character in other contexts such as /etc files >>> since the dawn of time). >> >> How should scripts unescape escaped separators? > > The "read" command handles this for you if you set IFS correctly (and > the escape character is \). hmm ... relying on people to set IFS seems somewhat more error-prone than providing an option to specify the field separation character of the parsable output (as was previously suggested). Michael -- Michael Schuster http://blogs.sun.com/recursion Recursion, n.: see 'Recursion' From Nicolas.Williams@sun.com Fri Jun 13 08:51:03 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DFp2Vj011694 for ; Fri, 13 Jun 2008 08:51:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5DFom7b027982; Fri, 13 Jun 2008 23:50:59 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00J0XS0XPS00@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 09:50:57 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00JH4S0W4I00@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 09:50:56 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5DFouW5020111; Fri, 13 Jun 2008 10:50:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5DFotMl020110; Fri, 13 Jun 2008 10:50:55 -0500 (CDT) Date: Fri, 13 Jun 2008 10:50:55 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <1213238096.5625.33.camel@seb> To: Sebastien Roy Cc: psarc-ext , John Leser , Peter Memishian Mail-followup-to: Sebastien Roy , psarc-ext , John Leser , Peter Memishian Message-id: <20080613155055.GG2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 867 On Wed, Jun 11, 2008 at 10:34:56PM -0400, Sebastien Roy wrote: > * Since it's possible that a field value could contain a literal > "|", parseable output will escape literal "|" as "\|", and > literal "\" as "\\". As it happens, this escape format is > already handled automatically by the "read" and "while read" > shell constructs, ensuring that parsing remains simple. % print ${.sh.version} Version M 1993-12-28 s+ % function d { typeset OIFS=$IFS typeset IFS='|' read line set -- $line IFS=$OIFS for i in "$@" do print -r -- arg: "$i" done } % echo 'a\|b|c' a\|b|c % echo 'a\|b|c' | d arg: a arg: b arg: c % function d { typeset OIFS=$IFS typeset IFS='|' read -r line set -- $line IFS=$OIFS for i in "$@" do print -r -- arg: "$i" done } % echo 'a\|b|c' | d arg: a\ arg: b arg: c % Nico -- From Nicolas.Williams@sun.com Fri Jun 13 08:53:01 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DFr1Hm011883 for ; Fri, 13 Jun 2008 08:53:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DFqrgP016689; Fri, 13 Jun 2008 08:52:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00M05S475000@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 08:52:55 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00GMNS467N50@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 08:52:54 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5DFqoBS020118; Fri, 13 Jun 2008 10:52:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5DFqosY020117; Fri, 13 Jun 2008 10:52:50 -0500 (CDT) Date: Fri, 13 Jun 2008 10:52:50 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <485295B1.9010407@Sun.COM> To: John Leser Cc: Peter Memishian , Darren Reed , Joseph Kowalski , Dan Mick , "Garrett D'Amore" , Sebastien Roy , John Plocher , psarc-ext Mail-followup-to: John Leser , Peter Memishian , Darren Reed , Joseph Kowalski , Dan Mick , Garrett D'Amore , Sebastien Roy , John Plocher , psarc-ext Message-id: <20080613155250.GH2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> <20080613153845.GF2735@Sun.COM> <485295B1.9010407@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 755 On Fri, Jun 13, 2008 at 11:43:45AM -0400, John Leser wrote: > Nicolas Williams wrote: > >On Fri, Jun 13, 2008 at 03:16:49AM -0400, Peter Memishian wrote: > >>Is this horse dead yet? > > > >No > > > >>Huh? The conclusion was already reached that the choice of separator is > >>immaterial since it will be quoted anyway. Pursuant to that, John and I > >>agreed to use ":" because it already has precedent with zoneadm(1M) (and > >>has been a Unix separator character in other contexts such as /etc files > >>since the dawn of time). > > > >How should scripts unescape escaped separators? > > The "read" command handles this for you if you set IFS correctly (and > the escape character is \). Thing is: I just tried it, and with ksh93 it doesn't work. From Peter.Memishian@sun.com Fri Jun 13 09:00:29 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DG0Thp012981 for ; Fri, 13 Jun 2008 09:00:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DG0Sm8026804; Fri, 13 Jun 2008 10:00:28 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00K07SGSE600@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 10:00:28 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00JCLSGR4I10@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 10:00:27 -0600 (MDT) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DG0MpP024001; Fri, 13 Jun 2008 12:00:22 -0400 (EDT) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5DG0MEa220524; Fri, 13 Jun 2008 12:00:22 -0400 (EDT) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5DG0MkL220521; Fri, 13 Jun 2008 12:00:22 -0400 (EDT) Date: Fri, 13 Jun 2008 12:00:22 -0400 From: Peter Memishian Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <485296FE.1060302@sun.com> To: Michael Schuster Cc: John.Leser@sun.com, Peter Memishian , Darren Reed , Joseph Kowalski , Dan Mick , "Garrett D'Amore" , Sebastien Roy , John Plocher , psarc-ext Reply-to: Peter.Memishian@sun.com Message-id: <18514.39318.11162.552762@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> <20080613153845.GF2735@Sun.COM> <485295B1.9010407@Sun.COM> <485296FE.1060302@sun.com> X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 1032 > >> How should scripts unescape escaped separators? > > > > The "read" command handles this for you if you set IFS correctly (and > > the escape character is \). > > hmm ... relying on people to set IFS seems somewhat more error-prone than > providing an option to specify the field separation character of the > parsable output (as was previously suggested). Again, the default value for IFS is unusable because it doesn't work properly with empty fields. Consider these two cases: 1. We allow a whitespace delimeter. Things *seem* to work until the first time the script stumbles on whitespace, and it breaks. 2. We don't allow whitespace. Nothing works until IFS is set. The second case is clearly less error-prone. Perhaps we're going over this again and again because the original spec wasn't detailed enough in covering all the background issues, and no one has been able to keep up with the subsequent email discussion. As such, I propose that John and I update the spec and resubmit. -- meem From John.Plocher@Sun.COM Fri Jun 13 09:49:14 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DGnDci016684 for ; Fri, 13 Jun 2008 09:49:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5DGnBW1019168 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 14 Jun 2008 00:49:12 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00503UPX1500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 09:49:10 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00GBKUPU7J90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 09:49:06 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5DGn5dR001001 for ; Fri, 13 Jun 2008 09:49:06 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00I01RR6T200@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 09:49:06 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E006GMUPEPX50@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 09:48:50 -0700 (PDT) Date: Fri, 13 Jun 2008 09:48:50 -0700 From: John Plocher Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852122B.9020409@Sun.COM> Sender: John.Plocher@Sun.COM To: Darren Reed Cc: John Leser , psarc-ext Message-id: <4852A4F2.7000505@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 2549 Darren Reed wrote: > To bring this back to where it started, the issues are (for PSARC): > - given that there will be future work that wants to generate > parsable output, do we need an opinion written up (for this case) > to serve as the notice of our decision about it or is it sufficient > to just cite this case? No opinion should be needed - though a best practice (written by Joe or Garrett or Nico or you or...) that summarizes this into something reusable would be good. Unlike Joe, I do not believe this is a one-off - we need structure and consistency in this area, and this case (like zoneadm) presents a reasonable way to provide it *if*, in fact, the project team can solve the escape sequence parsing problem). To me, that structure is: We (the ARC, Sun,...) do not want every utility to do one-off parsable output formats if we can help it - or to use different CLI utterances to obtain it. We want the output to be easily usable in the places where we expect it to be commonly used - shells, scripting languages, etc. And we don't need to handle every conceivable future possibility as part of this case. A spec that would work for me would say simply use command -t ':' -p -o xx,yy,zz to get tabular, ':' delimited and properly escaped output Here are examples of how to use this output: ksh93: ... perl: .... fortran: ... :-) ... > - if we're going to use this case as the foundation for all future > cases that are presenting output from commands, such as these, > that is meant to be parsable, do we: > 1) decide that we insist that commands use -o/-p unless history > prevents it? (i.e. new commands *MUST* use this combination) If new commands choose to provide parsable output, the CLIP guidelines strongly suggest use of a common CLI term. "-p" seems to be the one we have defacto standardized upon. Same for "-o aaa,bbb,ccc". And ":" as a separator. Wishing that we didn't have to parse command output so we wouldn't have to address this issue is IMO naive. The fact remains that it is common, useful and expedient to provide this type of data in tabular multiline form. If it turns out that it isn't easily parsable in shell, then we'll all just use perl or whatever - and not lose any sleep over it. Getting access to the data is the key enabler here - its exact format is secondary - if I can't get the data in the first place, it doesn't matter what format it isn't in. A revised spec would be good. -John From John.Leser@sun.com Fri Jun 13 10:02:38 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DH2cRj017392 for ; Fri, 13 Jun 2008 10:02:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DH2YwI008718 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 18:02:37 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00L03VCBUN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 10:02:35 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00K3PVCAZB20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 10:02:34 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5DH2YWr017543 for ; Fri, 13 Jun 2008 17:02:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00I01TC99300@mail-amer.sun.com> (original mail from John.Leser@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 11:02:34 -0600 (MDT) Received: from gir.East.Sun.COM ([129.148.174.24]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E00LACVBZVP60@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 11:02:24 -0600 (MDT) Date: Fri, 13 Jun 2008 13:03:59 -0400 From: John Leser Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080613155055.GG2735@Sun.COM> Sender: John.Leser@sun.com To: Sebastien Roy , psarc-ext , John Leser , Peter Memishian Reply-to: John.Leser@sun.com Message-id: <4852A87F.60002@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080613155055.GG2735@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 1278 It does work, the problem is your function d is using "set" to separate the fields rather than "read": $ print ${.sh.version} Version M 1993-12-28 s+ $ echo 'a\|b|c' | IFS="|" read v1; print "v1=$v1" v1=a|b|c $ echo 'a\|b|c' | IFS="|" read v1 v2 v3; print "v1=$v1 v2=$v2 v3=$v3" v1=a|b v2=c v3= -John Nicolas Williams wrote: > On Wed, Jun 11, 2008 at 10:34:56PM -0400, Sebastien Roy wrote: >> * Since it's possible that a field value could contain a literal >> "|", parseable output will escape literal "|" as "\|", and >> literal "\" as "\\". As it happens, this escape format is >> already handled automatically by the "read" and "while read" >> shell constructs, ensuring that parsing remains simple. > > % print ${.sh.version} > Version M 1993-12-28 s+ > % function d { > typeset OIFS=$IFS > typeset IFS='|' > read line > set -- $line > IFS=$OIFS > for i in "$@" > do > print -r -- arg: "$i" > done > } > % echo 'a\|b|c' > a\|b|c > % echo 'a\|b|c' | d > arg: a > arg: b > arg: c > % function d { > typeset OIFS=$IFS > typeset IFS='|' > read -r line > set -- $line > IFS=$OIFS > for i in "$@" > do > print -r -- arg: "$i" > done > } > % echo 'a\|b|c' | d > arg: a\ > arg: b > arg: c > % > > Nico From carlsonj@phorcys.east.sun.com Fri Jun 13 10:05:09 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DH58Qb017433 for ; Fri, 13 Jun 2008 10:05:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DH52mq028096; Fri, 13 Jun 2008 10:05:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E0010RVGJEJ00@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 11:05:07 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00JTWVGI4I60@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 11:05:06 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5DH568X018400; Fri, 13 Jun 2008 13:05:06 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5DH56wJ018397; Fri, 13 Jun 2008 13:05:06 -0400 (EDT) Date: Fri, 13 Jun 2008 13:05:06 -0400 From: James Carlson Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080613155055.GG2735@Sun.COM> To: Nicolas Williams Cc: Sebastien Roy , psarc-ext , Peter Memishian , John Leser Message-id: <18514.43202.360218.169257@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080613155055.GG2735@Sun.COM> Status: RO Content-Length: 597 Nicolas Williams writes: > % print ${.sh.version} > Version M 1993-12-28 s+ > % function d { > typeset OIFS=$IFS > typeset IFS='|' > read line > set -- $line Oops! You just told it to break up the arguments twice. Here's a better example: $ ksh93 -p $ echo 'a\:b:c' a\:b:c $ echo 'a\:b:c' | IFS=: read a b c $ echo $a a:b $ echo $b c $ echo $c $ It works fine. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@Sun.COM Fri Jun 13 10:06:19 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DH6Jac017501 for ; Fri, 13 Jun 2008 10:06:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DH6HxK028834; Fri, 13 Jun 2008 10:06:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E0061BVIIWB00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 10:06:18 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00G04VIH7I80@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 10:06:17 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5DH6HQp020240; Fri, 13 Jun 2008 12:06:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5DH6HDd020239; Fri, 13 Jun 2008 12:06:17 -0500 (CDT) Date: Fri, 13 Jun 2008 12:06:17 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18514.43202.360218.169257@gargle.gargle.HOWL> To: James Carlson Cc: Sebastien Roy , psarc-ext , Peter Memishian , John Leser Mail-followup-to: James Carlson , Sebastien Roy , psarc-ext , Peter Memishian , John Leser Message-id: <20080613170616.GQ2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080613155055.GG2735@Sun.COM> <18514.43202.360218.169257@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 265 On Fri, Jun 13, 2008 at 01:05:06PM -0400, James Carlson wrote: > Nicolas Williams writes: > > read line > > set -- $line > > Oops! You just told it to break up the arguments twice. Well, I suppose if I know a priori how many fields there are then all's good. From Nicolas.Williams@sun.com Fri Jun 13 10:11:04 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DHB4JB017732 for ; Fri, 13 Jun 2008 10:11:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DHAxrv012272; Fri, 13 Jun 2008 18:11:02 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E0070DVQCDS00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 10:11:00 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00GJXVQC7BA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 10:11:00 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5DHAxAj020247; Fri, 13 Jun 2008 12:11:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5DHAxls020246; Fri, 13 Jun 2008 12:10:59 -0500 (CDT) Date: Fri, 13 Jun 2008 12:10:59 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18514.43202.360218.169257@gargle.gargle.HOWL> To: James Carlson Cc: Sebastien Roy , psarc-ext , Peter Memishian , John Leser Mail-followup-to: James Carlson , Sebastien Roy , psarc-ext , Peter Memishian , John Leser Message-id: <20080613171059.GR2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080613155055.GG2735@Sun.COM> <18514.43202.360218.169257@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 658 On Fri, Jun 13, 2008 at 01:05:06PM -0400, James Carlson wrote: > Nicolas Williams writes: > > % print ${.sh.version} > > Version M 1993-12-28 s+ > > % function d { > > typeset OIFS=$IFS > > typeset IFS='|' > > read line > > set -- $line > > Oops! You just told it to break up the arguments twice. Er, actually, I didn't. The first read doesn't break up the arguments because it has a single variable named to it. The set ought to split up the line read in. Adding -r to the read invocation changes nothing. So maybe this is a shell bug, or maybe just a feature of read that the shell normally doesn't provide when breaking up arguments. Nico -- From John.Leser@Sun.COM Fri Jun 13 10:12:09 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DHC9TM017762 for ; Fri, 13 Jun 2008 10:12:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DHC3An016230 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 10:12:09 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00103VS8QU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 11:12:08 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00JG3VS84F60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 11:12:08 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5DHC8Q6021756 for ; Fri, 13 Jun 2008 17:12:08 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00601VNAHD00@mail-amer.sun.com> (original mail from John.Leser@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 11:12:08 -0600 (MDT) Received: from gir.East.Sun.COM ([129.148.174.24]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E007S0VR7N7C0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 11:11:32 -0600 (MDT) Date: Fri, 13 Jun 2008 13:13:07 -0400 From: John Leser Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080613170616.GQ2735@Sun.COM> Sender: John.Leser@Sun.COM To: James Carlson , Sebastien Roy , psarc-ext , Peter Memishian , John Leser Reply-to: John.Leser@Sun.COM Message-id: <4852AAA3.1050803@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080613155055.GG2735@Sun.COM> <18514.43202.360218.169257@gargle.gargle.HOWL> <20080613170616.GQ2735@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 698 Nicolas Williams wrote: > On Fri, Jun 13, 2008 at 01:05:06PM -0400, James Carlson wrote: >> Nicolas Williams writes: >>> read line >>> set -- $line >> Oops! You just told it to break up the arguments twice. > > Well, I suppose if I know a priori how many fields there are then all's > good. > "Further, we propose that the existing "-o" switch (which is used to enumerate fields to display) be required in parseable output mode. This ensure that we will be able to add new fields in the future without potentially breaking existing scripts." We force the user to know exactly what they are asking for to avoid the case were more fields are added and their scripts break. -John From gdamore@sun.com Fri Jun 13 10:21:03 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DHL13p017819 for ; Fri, 13 Jun 2008 10:21:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5DHKvag029438 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 14 Jun 2008 01:21:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00M09W6YKX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 10:20:58 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00KPNW6XZ120@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 10:20:57 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5DHKv6e005638 for ; Fri, 13 Jun 2008 10:20:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00C01VOO3A00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 10:20:57 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E003TDW6WK4E0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 10:20:56 -0700 (PDT) Date: Fri, 13 Jun 2008 10:19:52 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852A4F2.7000505@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Darren Reed , John Leser , psarc-ext Message-id: <4852AC38.9020803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <4852A4F2.7000505@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 5377 I still have a philosophical objection to the idea that we are going to standardize some kind of tabular format for utilities to "dump" their data for further massaging ("parsing") by shell scripts. I'm not opposed to the idea that shell scripts need to access the data that is in these "databases", I just don't think that a general opinion providing a way to dump the "whole" database for subsystem X (whatever the subsystem is) is really the best approach, and I'm fairly confident that whatever we settle upon, native parsing will become difficult for at least some dialect. (E.g. dealing with escaped characters may be easy for a particular version of sh, but what about for awk or perl or for that matter Java? There already seems to be anecdotal evidence that even sh versus ksh93 have some annoying differences in their handling of read.) If we need programmatic access to this data from shell scripts and such, then lets quit trying to solve the problem by dumping the entire state at once to the shell, and offer utilities to extract the state and present it in a format so that shell scripts *don't* have to "parse" it. My favored option is still the -o type of solution, with some other option indicating a look up key (assuming that is pertinent.) I don't think the ability to choose different delimiters is really that important here, nor, IMO, is the ability to dump more than a single field in an invocation. Both of those wind up raising the whole "parsing" question because you have to find a neutral delimiter, and thus require token parsing of some sort. (Hmm... that does still leave the issue of listing all the records ala zfs list, open, but *probably* its safe to assume that we can separate records by newlines.) That said, if, as a one-off solution, there is a desire to dump more information at once, I don't see a problem with inventing a special format for it. I just don't think we're likely to standardize on one that works everywhere. Instead, we should, IMO, discourage the creation of solutions which require token separation to be performed by shell scripts. Alternatively, we can provide tools which perform general format parsing on behalf of the shells and have the parseable format come in such a format. (The tools I'm talking about would perform lookup and field extraction on behalf of the calling script.) I'd advise in such a case against inventing yet another new file format though. (I think I already mentioned XML. Likely something simpler, such as CSV or tab-delimited fields, would be more palatable. It would certainly make processing easier for languages that don't already have XML support.) -- Garrett John Plocher wrote: > Darren Reed wrote: >> To bring this back to where it started, the issues are (for PSARC): >> - given that there will be future work that wants to generate >> parsable output, do we need an opinion written up (for this case) >> to serve as the notice of our decision about it or is it sufficient >> to just cite this case? > > No opinion should be needed - though a best practice (written by Joe > or Garrett or Nico or you or...) that summarizes this into something > reusable would be good. > > Unlike Joe, I do not believe this is a one-off - we need structure > and consistency in this area, and this case (like zoneadm) presents > a reasonable way to provide it *if*, in fact, the project team can > solve the escape sequence parsing problem). > > To me, that structure is: > > We (the ARC, Sun,...) do not want every utility to do > one-off parsable output formats if we can help it - or > to use different CLI utterances to obtain it. We want > the output to be easily usable in the places where we > expect it to be commonly used - shells, scripting languages, > etc. And we don't need to handle every conceivable future > possibility as part of this case. > > A spec that would work for me would say simply > use > command -t ':' -p -o xx,yy,zz > to get tabular, ':' delimited and properly escaped output > > Here are examples of how to use this output: > > ksh93: ... > perl: .... > fortran: ... :-) ... > > > > >> - if we're going to use this case as the foundation for all future >> cases that are presenting output from commands, such as these, >> that is meant to be parsable, do we: >> 1) decide that we insist that commands use -o/-p unless history >> prevents it? (i.e. new commands *MUST* use this combination) > > If new commands choose to provide parsable output, the CLIP > guidelines strongly suggest use of a common CLI term. "-p" seems > to be the one we have defacto standardized upon. > > Same for "-o aaa,bbb,ccc". And ":" as a separator. > > Wishing that we didn't have to parse command output so we wouldn't > have to address this issue is IMO naive. The fact remains that > it is common, useful and expedient to provide this type of data > in tabular multiline form. If it turns out that it isn't easily > parsable in shell, then we'll all just use perl or whatever - and > not lose any sleep over it. Getting access to the data is the key > enabler here - its exact format is secondary - if I can't get the > data in the first place, it doesn't matter what format it isn't in. > > A revised spec would be good. > > -John > From carlsonj@phorcys.east.sun.com Fri Jun 13 10:30:18 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DHUI9c018234 for ; Fri, 13 Jun 2008 10:30:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DHUHld058475; Fri, 13 Jun 2008 11:30:17 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00M01WMGXZ00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 10:30:16 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00K0LWMFZ840@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 10:30:16 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5DHUFtm018542; Fri, 13 Jun 2008 13:30:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5DHUFXk018539; Fri, 13 Jun 2008 13:30:15 -0400 (EDT) Date: Fri, 13 Jun 2008 13:30:15 -0400 From: James Carlson Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <20080613171059.GR2735@Sun.COM> To: Nicolas Williams Cc: psarc-ext , Sebastien Roy , John Leser , Peter Memishian Message-id: <18514.44711.668288.769612@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080613155055.GG2735@Sun.COM> <18514.43202.360218.169257@gargle.gargle.HOWL> <20080613171059.GR2735@Sun.COM> Status: RO Content-Length: 590 Nicolas Williams writes: > So maybe this is a shell bug, or maybe just a feature of read that the > shell normally doesn't provide when breaking up arguments. I don't know of any way to do it just with 'set', and in the scripts I've written using zoneadm, I haven't found it to be a limitation. But this probably isn't the right for a shell scripting contest. :-/ -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Sebastien.Roy@sun.com Fri Jun 13 10:31:52 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DHVpXB018279 for ; Fri, 13 Jun 2008 10:31:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5DHVdrj002518 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 14 Jun 2008 01:31:50 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00N0NWP10F00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 10:31:49 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00K7LWP0Z840@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 10:31:49 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5DHVm6C016365 for ; Fri, 13 Jun 2008 17:31:48 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00B01VXYJB00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 11:31:48 -0600 (MDT) Received: from [192.168.1.5] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E00BVXWOSJA50@mail-amer.sun.com>; Fri, 13 Jun 2008 11:31:41 -0600 (MDT) Date: Fri, 13 Jun 2008 13:31:39 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18514.39318.11162.552762@gargle.gargle.HOWL> Sender: Sebastien.Roy@sun.com To: Peter.Memishian@sun.com Cc: Michael Schuster , John.Leser@sun.com, Darren Reed , Joseph Kowalski , Dan Mick , "Garrett D'Amore" , John Plocher , psarc-ext Message-id: <1213378299.4770.26.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> <20080613153845.GF2735@Sun.COM> <485295B1.9010407@Sun.COM> <485296FE.1060302@sun.com> <18514.39318.11162.552762@gargle.gargle.HOWL> Status: RO Content-Length: 669 On Fri, 2008-06-13 at 12:00 -0400, Peter Memishian wrote: > Perhaps we're going over this again and again because the original spec > wasn't detailed enough in covering all the background issues, and no one > has been able to keep up with the subsequent email discussion. As such, > I propose that John and I update the spec and resubmit. Agreed. The changes to the spec should include the change in field separator and a diff-marked dladm(1M) man page. Perhaps more usage examples in the spec would also help, in addition to examples in the man page. People, please wait to comment further until the spec has been updated and you have re-read it. Thanks, -Seb From Sebastien.Roy@sun.com Fri Jun 13 11:22:02 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DIM2hp022474 for ; Fri, 13 Jun 2008 11:22:02 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DIM1T7020104 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 11:22:02 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E00F0PZ0P4Y00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 11:22:01 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00GIVZ0P7ID0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 11:22:01 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5DIM11c007136 for ; Fri, 13 Jun 2008 18:22:01 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00G01YKZ0O00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 12:22:01 -0600 (MDT) Received: from [192.168.1.5] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E001C3Z0GV7H0@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 12:21:53 -0600 (MDT) Date: Fri, 13 Jun 2008 14:21:52 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852AC38.9020803@sun.com> Sender: Sebastien.Roy@sun.com To: "Garrett D'Amore" Cc: John Plocher , John Leser , Darren Reed , psarc-ext Message-id: <1213381312.4770.39.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <4852A4F2.7000505@Sun.Com> <4852AC38.9020803@sun.com> Status: RO Content-Length: 297 On Fri, 2008-06-13 at 10:19 -0700, Garrett D'Amore wrote: > That said, if, as a one-off solution, there is a desire to dump more > information at once, I don't see a problem with inventing a special > format for it. Great, then please end this discussion and wait for the updated spec. -Seb From gdamore@sun.com Fri Jun 13 11:23:38 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DINboP022572 for ; Fri, 13 Jun 2008 11:23:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DINRYg009406 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 19:23:36 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2E0060HZ397U00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 12:23:33 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2E00J0XZ384IC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 12:23:32 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5DINW2n001985 for ; Fri, 13 Jun 2008 11:23:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2E00401YXD8U00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 11:23:32 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2E007F3Z32UUD0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 11:23:26 -0700 (PDT) Date: Fri, 13 Jun 2008 11:22:22 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852AC38.9020803@sun.com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Darren Reed , John Leser , psarc-ext Message-id: <4852BADE.8080504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <4852A4F2.7000505@Sun.Com> <4852AC38.9020803@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 5959 In case it wasn't clear, the whole message below was in reference to some proposed new CLIP-like standard for programs to follow. I have little objection with a case-by-case addition of parsed output (such as here), although I'd encourage project teams to consider whether a full state dump is truly the best way to provide data to script authors. (It may or may not be.) -- Garrett Garrett D'Amore wrote: > I still have a philosophical objection to the idea that we are going > to standardize some kind of tabular format for utilities to "dump" > their data for further massaging ("parsing") by shell scripts. > > I'm not opposed to the idea that shell scripts need to access the data > that is in these "databases", I just don't think that a general > opinion providing a way to dump the "whole" database for subsystem X > (whatever the subsystem is) is really the best approach, and I'm > fairly confident that whatever we settle upon, native parsing will > become difficult for at least some dialect. (E.g. dealing with > escaped characters may be easy for a particular version of sh, but > what about for awk or perl or for that matter Java? There already > seems to be anecdotal evidence that even sh versus ksh93 have some > annoying differences in their handling of read.) > > If we need programmatic access to this data from shell scripts and > such, then lets quit trying to solve the problem by dumping the entire > state at once to the shell, and offer utilities to extract the state > and present it in a format so that shell scripts *don't* have to > "parse" it. > > My favored option is still the -o type of solution, with some other > option indicating a look up key (assuming that is pertinent.) I don't > think the ability to choose different delimiters is really that > important here, nor, IMO, is the ability to dump more than a single > field in an invocation. Both of those wind up raising the whole > "parsing" question because you have to find a neutral delimiter, and > thus require token parsing of some sort. (Hmm... that does still > leave the issue of listing all the records ala zfs list, open, but > *probably* its safe to assume that we can separate records by newlines.) > > That said, if, as a one-off solution, there is a desire to dump more > information at once, I don't see a problem with inventing a special > format for it. I just don't think we're likely to standardize on one > that works everywhere. Instead, we should, IMO, discourage the > creation of solutions which require token separation to be performed > by shell scripts. > > Alternatively, we can provide tools which perform general format > parsing on behalf of the shells and have the parseable format come in > such a format. (The tools I'm talking about would perform lookup and > field extraction on behalf of the calling script.) I'd advise in such > a case against inventing yet another new file format though. (I > think I already mentioned XML. Likely something simpler, such as CSV > or tab-delimited fields, would be more palatable. It would certainly > make processing easier for languages that don't already have XML > support.) > > -- Garrett > > John Plocher wrote: >> Darren Reed wrote: >>> To bring this back to where it started, the issues are (for PSARC): >>> - given that there will be future work that wants to generate >>> parsable output, do we need an opinion written up (for this case) >>> to serve as the notice of our decision about it or is it sufficient >>> to just cite this case? >> >> No opinion should be needed - though a best practice (written by Joe >> or Garrett or Nico or you or...) that summarizes this into something >> reusable would be good. >> >> Unlike Joe, I do not believe this is a one-off - we need structure >> and consistency in this area, and this case (like zoneadm) presents >> a reasonable way to provide it *if*, in fact, the project team can >> solve the escape sequence parsing problem). >> >> To me, that structure is: >> >> We (the ARC, Sun,...) do not want every utility to do >> one-off parsable output formats if we can help it - or >> to use different CLI utterances to obtain it. We want >> the output to be easily usable in the places where we >> expect it to be commonly used - shells, scripting languages, >> etc. And we don't need to handle every conceivable future >> possibility as part of this case. >> >> A spec that would work for me would say simply >> use >> command -t ':' -p -o xx,yy,zz >> to get tabular, ':' delimited and properly escaped output >> >> Here are examples of how to use this output: >> >> ksh93: ... >> perl: .... >> fortran: ... :-) ... >> >> >> >> >>> - if we're going to use this case as the foundation for all future >>> cases that are presenting output from commands, such as these, >>> that is meant to be parsable, do we: >>> 1) decide that we insist that commands use -o/-p unless history >>> prevents it? (i.e. new commands *MUST* use this combination) >> >> If new commands choose to provide parsable output, the CLIP >> guidelines strongly suggest use of a common CLI term. "-p" seems >> to be the one we have defacto standardized upon. >> >> Same for "-o aaa,bbb,ccc". And ":" as a separator. >> >> Wishing that we didn't have to parse command output so we wouldn't >> have to address this issue is IMO naive. The fact remains that >> it is common, useful and expedient to provide this type of data >> in tabular multiline form. If it turns out that it isn't easily >> parsable in shell, then we'll all just use perl or whatever - and >> not lose any sleep over it. Getting access to the data is the key >> enabler here - its exact format is secondary - if I can't get the >> data in the first place, it doesn't matter what format it isn't in. >> >> A revised spec would be good. >> >> -John >> > From roland.mainz@nrubsig.org Fri Jun 13 12:18:35 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DJIYqK028021 for ; Fri, 13 Jun 2008 12:18:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DJIPJv020486; Fri, 13 Jun 2008 20:18:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F004011MSE000@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 12:18:28 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F00K8P1MRZCD0@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 12:18:27 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5DJIRl6020693; Fri, 13 Jun 2008 19:18:27 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay44i.sun.com with ESMTP id BT-MMP-587046; Fri, 13 Jun 2008 19:18:27 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-30378383; Fri, 13 Jun 2008 19:18:26 +0000 (Z) Received: from mail-in-14.arcor-online.net ([151.189.21.54] [151.189.21.54]) by relay4i.sun.com with ESMTP id BT-MMP-4101120; Fri, 13 Jun 2008 19:18:26 +0000 (Z) Received: from mail-in-12-z2.arcor-online.net (mail-in-12-z2.arcor-online.net [151.189.8.29]) by mail-in-14.arcor-online.net (Postfix) with ESMTP id 132101878EC; Fri, 13 Jun 2008 21:18:24 +0200 (CEST) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-12-z2.arcor-online.net (Postfix) with ESMTP id 01579279436; Fri, 13 Jun 2008 21:18:24 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-200-196.pools.arcor-ip.net [84.58.200.196]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id 9E85235E71E; Fri, 13 Jun 2008 21:18:23 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m5DJILJb006051; Fri, 13 Jun 2008 21:18:21 +0200 (CEST) Date: Fri, 13 Jun 2008 21:18:21 +0200 From: Roland Mainz Subject: Structured information in shells... / was: Re: PSARC 2008/374 dladm parseable output Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Joseph Kowalski , John Leser , Darren Reed , Sebastien Roy , John Plocher , Peter.Memishian@sun.com, psarc-ext Message-id: <4852C7FD.CB817417@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.93/7407/Mon Jun 9 04:21:00 2008 on mail-in-06.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.098sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <4851F052.6070103@sun.com> Status: RO Content-Length: 1939 Garrett D'Amore wrote: > Nicolas Williams wrote: > > On Thu, Jun 12, 2008 at 08:34:33PM -0700, Garrett D'Amore wrote: [snip] > The question isn't about discouraging scripting, but rather, how far do > we want to go to enable people to use a shell script to perform > something that they really probably should have a better tool for? > > I get the feeling that we're trying to represent what is really > structured data, to a language that doesn't have even the slightest > concept of data structures. Erm... I suggest to stop designing stuff around the old Bourne shell or treating all shells like the Bourne shell (if we go down to that level we can easily _lower_ it by making the Thomson shell (predecessor of the Bourne shell) the _minimum_ level for this case. IMO a reasonable _minimum_ level should be the POSIX shell specification - which would solve lots of trouble this case has...). For example ksh93 has support for |struct|-like variables which can be nested like this: -- snip -- $ ksh93 -c 'x=( a=5 b="hello" c=( d=9 e="hello world" ) ) ; print "$x"' ( a=5 b=hello c=( d=9 e='hello world' ) ) -- snip -- This kind of variable tree can be nested without any limits - see http://www.nrubsig.org/people/gisburn/work/sun/xserver_license_extractor/X-src-20071107_XW_NV_open-src_tarballs_extraced_comments20080331.cpv for a simply example of an array value. The largest variable tree so far on production systems contained ~~30GB (GigaBytes!!) of data (and it was _not_ slower than a JAVA or C++ application to build and crawl the tree (e.g. stop speading the "FUD" that "shells are slow". It may apply to the Bourne shell but the shells did evolve since that a bit...)). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From scott.rotondo@sun.com Fri Jun 13 12:27:19 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DJRJfp028771 for ; Fri, 13 Jun 2008 12:27:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DJRIjf014798; Fri, 13 Jun 2008 12:27:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F00M1H21IAF00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 12:27:18 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F00M1821EAM00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 12:27:14 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5DJRE0S665258; Fri, 13 Jun 2008 12:27:14 -0700 (PDT) Date: Fri, 13 Jun 2008 12:27:14 -0700 From: Scott Rotondo Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852A4F2.7000505@Sun.Com> To: John Plocher Cc: psarc-ext Message-id: <4852CA12.9070007@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <4852A4F2.7000505@Sun.Com> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 2112 In spite of the truly astounding amount of commentary this case has generated, the discussion does appear to be converging on a useful pattern for utilities to follow. John Plocher wrote: > We (the ARC, Sun,...) do not want every utility to do > one-off parsable output formats if we can help it - or > to use different CLI utterances to obtain it. We want > the output to be easily usable in the places where we > expect it to be commonly used - shells, scripting languages, > etc. And we don't need to handle every conceivable future > possibility as part of this case. > > A spec that would work for me would say simply > use > command -t ':' -p -o xx,yy,zz > to get tabular, ':' delimited and properly escaped output I think this is a good pattern to follow, but it should be customized for specific commands: 1. The -p option (for parseable output) is only needed if the command normally produces unparseable output. If it's the default, there is no need to have an option that is silently ignored. 2. For most commands, I don't think the -t option to specify the delimiter is necessary or useful. The choice of delimiter is generally made by picking a character unlikely to occur in the data (and thus need escaping). Surely the author of the command is in the best position to make this determination. Aside from general text processing utilities, allowing the consumer to change the delimiter isn't that useful. [Another nit: I think there may be equal or greater use of -d instead of -t for this purpose in existing commands.] 3. I think Joe's suggestion to avoid parsing entirely by retrieving just one field at a time makes a lot of sense. A command that accepts only a single field name argument to -o should be an acceptable special case of this pattern. At this point, I think it would make sense to capture the guidance above, including the special cases, as the pattern for future commands to follow. It also makes sense to approve syntax for dladm that follows this pattern, as I believe the current proposal does. Scott From jek3@sun.com Fri Jun 13 13:01:55 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DK1sqO000382 for ; Fri, 13 Jun 2008 13:01:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DK1pes056181; Fri, 13 Jun 2008 14:01:51 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F00D033N3YE00@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 14:01:51 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F008T43N2UH40@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 14:01:50 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5DK1nB5671150; Fri, 13 Jun 2008 13:01:49 -0700 (PDT) Date: Fri, 13 Jun 2008 10:04:34 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <18514.39318.11162.552762@gargle.gargle.HOWL> To: Peter.Memishian@sun.com Cc: Michael Schuster , John.Leser@sun.com, Darren Reed , Dan Mick , "Garrett D'Amore" , Sebastien Roy , John Plocher , psarc-ext Message-id: <4852D2D2.9090104@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> <20080613153845.GF2735@Sun.COM> <485295B1.9010407@Sun.COM> <485296FE.1060302@sun.com> <18514.39318.11162.552762@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 793 Peter Memishian wrote: > Perhaps we're going over this again and again because the original spec > wasn't detailed enough in covering all the background issues, and no one > has been able to keep up with the subsequent email discussion. As such, > I propose that John and I update the spec and resubmit. > Partly. I believe the other thing is that many of us are having trouble believing that this whole method is appropriate for enough cases to be anything close to a "general solution". I look forward to seeing an updated proposal. I hope it contains: This proposal is specifically for dladm. The method employed may be useful for use by other utilities, but this does not establish a guideline or precidence. Or something like that. When I wish upon a star... - jek3 From gdamore@sun.com Fri Jun 13 13:09:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DK9i6H001309 for ; Fri, 13 Jun 2008 13:09:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DK9aag010514 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 21:09:43 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F00E05407JW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 14:09:43 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F008B8406UN40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 14:09:42 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5DK9gq3013484 for ; Fri, 13 Jun 2008 13:09:42 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2F00F013QZG600@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 13:09:42 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2F00FTV404SQ90@fe-sfbay-10.sun.com>; Fri, 13 Jun 2008 13:09:40 -0700 (PDT) Date: Fri, 13 Jun 2008 13:08:36 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852D2D2.9090104@sun.com> Sender: Garrett.Damore@sun.com To: Joseph Kowalski Cc: Peter.Memishian@sun.com, Michael Schuster , John.Leser@sun.com, Darren Reed , Dan Mick , Sebastien Roy , John Plocher , psarc-ext Message-id: <4852D3C4.7010105@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> <20080613153845.GF2735@Sun.COM> <485295B1.9010407@Sun.COM> <485296FE.1060302@sun.com> <18514.39318.11162.552762@gargle.gargle.HOWL> <4852D2D2.9090104@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1158 Joseph Kowalski wrote: > Peter Memishian wrote: >> Perhaps we're going over this again and again because the original spec >> wasn't detailed enough in covering all the background issues, and no one >> has been able to keep up with the subsequent email discussion. As such, >> I propose that John and I update the spec and resubmit. >> > > Partly. > > I believe the other thing is that many of us are having trouble > believing that this whole method is appropriate for enough cases to be > anything close to a "general solution". > > I look forward to seeing an updated proposal. I hope it contains: > > This proposal is specifically for dladm. The method employed may > be useful for use by other utilities, but this does not establish a > guideline or precidence. > > Or something like that. > > When I wish upon a star... +1. All of my other complaints/arguments related to the attempt to extend this case beyond dladm. Creation of a new, perhaps non-obvious, parsed language/file format as a generic standard for everyone else to use starts to get difficult (and probably fails the "obvious" test for fast tracks.) -- Garrett From jek3@sun.com Fri Jun 13 13:14:04 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DKE4FL001644 for ; Fri, 13 Jun 2008 13:14:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DKE0il027268; Fri, 13 Jun 2008 13:14:01 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F0070347C3J00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 13:14:00 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F006QU47C7C10@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 13:14:00 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5DKDx3V672839; Fri, 13 Jun 2008 13:13:59 -0700 (PDT) Date: Fri, 13 Jun 2008 10:16:45 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852A4F2.7000505@Sun.Com> To: John Plocher Cc: Darren Reed , John Leser , psarc-ext Message-id: <4852D5AD.8060400@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <4852A4F2.7000505@Sun.Com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1137 John Plocher wrote: > Unlike Joe, I do not believe this is a one-off - we need structure > and consistency in this area, and this case (like zoneadm) presents > a reasonable way to provide it *if*, in fact, the project team can OK. I derail. I need no other justification beyond: 6: ls -l `pwd`/mail -rw-rw-r-- 1 daemon sac 311893 Jun 13 13:01 /shared/sac/PSARC/2008/374/mail As Tim has suggested, e-mail is a terrible tool for these discussions. BTW: I said *either* this is a "one-off" *or* it needs significant discussion. My suggestion was that rather than polishing this particular piece of teak, the project team would probably do themselves the best by just making this a "one off" and not trying to pass their particular brand of Kool-Aid. We all have priorities. Is making this a precedent or solution to world hunger the best use of our time? I suspect we can all find a bug to work on with a higher priority than designing a general solution for "parsable output", particularly when have a lot of precedence that "Parsable output is generally bad. Only use it when you must". - jek3 From roland.mainz@nrubsig.org Fri Jun 13 13:20:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DKKJkk002277 for ; Fri, 13 Jun 2008 13:20:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5DKKBSU014202; Fri, 13 Jun 2008 21:20:13 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F00F094HOF300@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 14:20:12 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F008B74HOUO50@brm-avmta-1.central.sun.com>; Fri, 13 Jun 2008 14:20:12 -0600 (MDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5DKIUcR016978; Fri, 13 Jun 2008 20:20:11 +0000 (GMT) Received: from mms22es.mms.us.syntegra.com ([150.143.232.30] [150.143.232.30]) by relay21i.sun.com with ESMTP id BT-MMP-1941429; Fri, 13 Jun 2008 20:20:11 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms22es.mms.us.syntegra.com with ESMTP id BT-MMP-31014196; Fri, 13 Jun 2008 20:20:09 +0000 (Z) Received: from mail-in-03.arcor-online.net ([151.189.21.43] [151.189.21.43]) by relay22i.sun.com with ESMTP id BT-MMP-38436611; Fri, 13 Jun 2008 20:20:09 +0000 (Z) Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id E175E2CB068; Fri, 13 Jun 2008 22:20:07 +0200 (CEST) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id B64872DAAD0; Fri, 13 Jun 2008 22:20:07 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-200-196.pools.arcor-ip.net [84.58.200.196]) by mail-in-11.arcor-online.net (Postfix) with ESMTP id B0371261302; Fri, 13 Jun 2008 22:20:06 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m5DKK4a8006073; Fri, 13 Jun 2008 22:20:05 +0200 (CEST) Date: Fri, 13 Jun 2008 22:20:04 +0200 From: Roland Mainz Subject: Re: PSARC 2008/374 dladm parseable output Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Joseph Kowalski , John Plocher , John.Leser@sun.com, Dan Mick , psarc-ext , Sebastien Roy , Michael Schuster , Darren Reed , Peter.Memishian@sun.com Message-id: <4852D674.D48C2890@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.93/7407/Mon Jun 9 04:21:00 2008 on mail-in-11.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 1.555sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> <20080613153845.GF2735@Sun.COM> <485295B1.9010407@Sun.COM> <485296FE.1060302@sun.com> <18514.39318.11162.552762@gargle.gargle.HOWL> <4852D2D2.9090104@sun.com> <4852D3C4.7010105@sun.com> Status: RO Content-Length: 737 Garrett D'Amore wrote: > Joseph Kowalski wrote: [snip] > All of my other complaints/arguments related to the attempt to extend > this case beyond dladm. Creation of a new, perhaps non-obvious, parsed > language/file format as a generic standard for everyone else to use > starts to get difficult (and probably fails the "obvious" test for fast > tracks.) Erm.. it would be nice not to "threaten" other people's project (like the libcompoundvar.so.1 one) with a "full ARC case" just because they want to address a generic problem at the root... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From jek3@sun.com Fri Jun 13 13:26:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DKQA9O003114 for ; Fri, 13 Jun 2008 13:26:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DKQ8LN061845 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 14:26:10 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F007034RKON00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 13:26:08 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F006MI4RJ6Z10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 13:26:07 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5DKQ662675184 for ; Fri, 13 Jun 2008 13:26:07 -0700 (PDT) Date: Fri, 13 Jun 2008 10:28:52 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852A87F.60002@Sun.COM> To: psarc-ext Message-id: <4852D884.8010700@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FG/GRxRcawumfy7L2blynQ)" X-PMX-Version: 5.4.1.325704 References: <1213238096.5625.33.camel@seb> <20080613155055.GG2735@Sun.COM> <4852A87F.60002@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 5489 This is a multi-part message in MIME format. --Boundary_(ID_FG/GRxRcawumfy7L2blynQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT One of the tenants of this case is: > In general, it's helpful for building administrative scripts as well as > test cases that there be some way to cause commands to issue output in > a format that is stable and *easy for scripts to parse*. It seems that it's so easy, that some of our "best and brightest" can't write to this specification. Just a thought.... :-) - jek3 John Leser wrote: > > It does work, the problem is your function d is using "set" to > separate the fields rather than "read": > > $ print ${.sh.version} > Version M 1993-12-28 s+ > $ echo 'a\|b|c' | IFS="|" read v1; print "v1=$v1" > v1=a|b|c > $ echo 'a\|b|c' | IFS="|" read v1 v2 v3; print "v1=$v1 v2=$v2 v3=$v3" > v1=a|b v2=c v3= > > -John > > Nicolas Williams wrote: >> On Wed, Jun 11, 2008 at 10:34:56PM -0400, Sebastien Roy wrote: >>> * Since it's possible that a field value could contain a >>> literal >>> "|", parseable output will escape literal "|" as "\|", and >>> literal "\" as "\\". As it happens, this escape format is >>> already handled automatically by the "read" and "while read" >>> shell constructs, ensuring that parsing remains simple. >> >> % print ${.sh.version} >> Version M 1993-12-28 s+ >> % function d { >> typeset OIFS=$IFS >> typeset IFS='|' >> read line >> set -- $line >> IFS=$OIFS >> for i in "$@" >> do >> print -r -- arg: "$i" >> done >> } >> % echo 'a\|b|c' >> a\|b|c >> % echo 'a\|b|c' | d >> arg: a >> arg: b >> arg: c >> % function d { >> typeset OIFS=$IFS >> typeset IFS='|' >> read -r line >> set -- $line >> IFS=$OIFS >> for i in "$@" >> do >> print -r -- arg: "$i" >> done >> } >> % echo 'a\|b|c' | d >> arg: a\ >> arg: b >> arg: c >> % >> Nico > > --Boundary_(ID_FG/GRxRcawumfy7L2blynQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
One of the tenants of this case is:

   In general, it's helpful for building administrative scripts as well as
   test cases that there be some way to cause commands to issue output in
   a format that is stable and easy for scripts to parse. 
It seems that it's so easy, that some of our "best and brightest" can't write to this specification.

Just a thought....   :-)

- jek3



John Leser wrote:

It does work, the problem is your function d is using "set" to separate the fields rather than "read":

$ print ${.sh.version}
Version M 1993-12-28 s+
$ echo 'a\|b|c' | IFS="|" read v1;  print "v1=$v1"
v1=a|b|c
$ echo 'a\|b|c' | IFS="|" read v1 v2 v3; print "v1=$v1 v2=$v2 v3=$v3"
v1=a|b v2=c v3=

-John

Nicolas Williams wrote:
On Wed, Jun 11, 2008 at 10:34:56PM -0400, Sebastien Roy wrote:
        * Since it's possible that a field value could contain a literal
          "|", parseable output will escape literal "|" as "\|", and
          literal "\" as "\\".  As it happens, this escape format is
          already handled automatically by the "read" and "while read"
          shell constructs, ensuring that parsing remains simple.

% print ${.sh.version}
Version M 1993-12-28 s+
% function d {
    typeset OIFS=$IFS
    typeset IFS='|'
    read line
    set -- $line
    IFS=$OIFS
    for i in "$@"
    do
        print -r -- arg: "$i"
    done
}
% echo 'a\|b|c'
a\|b|c
% echo 'a\|b|c' | d
arg: a
arg: b
arg: c
% function d {
    typeset OIFS=$IFS
    typeset IFS='|'
    read -r line
    set -- $line
    IFS=$OIFS
    for i in "$@"
    do
        print -r -- arg: "$i"
    done
}
% echo 'a\|b|c' | d
arg: a\
arg: b
arg: c
%
Nico



--Boundary_(ID_FG/GRxRcawumfy7L2blynQ)-- From jek3@Sun.COM Fri Jun 13 13:49:43 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DKnhO5005510 for ; Fri, 13 Jun 2008 13:49:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DKncjx001309; Fri, 13 Jun 2008 14:49:39 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F008055UQH600@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 13:49:38 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F008DI5UQ0P10@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Jun 2008 13:49:38 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5DKnamA682268; Fri, 13 Jun 2008 13:49:36 -0700 (PDT) Date: Fri, 13 Jun 2008 10:52:21 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852D674.D48C2890@nrubsig.org> To: Roland Mainz Cc: "Garrett D'Amore" , John Plocher , John.Leser@Sun.COM, Dan Mick , psarc-ext , Sebastien Roy , Michael Schuster , Darren Reed , Peter.Memishian@Sun.COM Message-id: <4852DE05.6010108@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_UHm5Cl/ORNySjg/uH54hFQ)" X-PMX-Version: 5.4.1.325704 References: <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <48521644.5040403@sun.com> <18514.6361.177137.678731@gargle.gargle.HOWL> <48521CBA.1030400@Sun.COM> <18514.7905.990388.114601@gargle.gargle.HOWL> <20080613153845.GF2735@Sun.COM> <485295B1.9010407@Sun.COM> <485296FE.1060302@sun.com> <18514.39318.11162.552762@gargle.gargle.HOWL> <4852D2D2.9090104@sun.com> <4852D3C4.7010105@sun.com> <4852D674.D48C2890@nrubsig.org> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 35713 This is a multi-part message in MIME format. --Boundary_(ID_UHm5Cl/ORNySjg/uH54hFQ) Content-type: multipart/alternative; boundary="Boundary_(ID_IKEtc9izoYegYp3wum8lFg)" --Boundary_(ID_IKEtc9izoYegYp3wum8lFg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Roland Mainz wrote: > Garrett D'Amore wrote: > >> Joseph Kowalski wrote: >> > [snip] > >> All of my other complaints/arguments related to the attempt to extend >> this case beyond dladm. Creation of a new, perhaps non-obvious, parsed >> language/file format as a generic standard for everyone else to use >> starts to get difficult (and probably fails the "obvious" test for fast >> tracks.) >> > > Erm.. it would be nice not to "threaten" other people's project (like > the libcompoundvar.so.1 one) with a "full ARC case" just because they > want to address a generic problem at the root... ;-( > > ---- > > Bye, > Roland > Erm,... yourself! Full cases are probably appropriate in this case. The problem is that somehow there seems to be a belief that full cases need to be hard. Not sure if this is a real problem or a perceived problem. This is the problem. Real architects should relish to opportunity to address the problem at the root. They should not do that as a side-effect of a specific project. - jek3 --Boundary_(ID_IKEtc9izoYegYp3wum8lFg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Roland Mainz wrote: 
Garrett D'Amore wrote:
  
Joseph Kowalski wrote:
    
[snip] 
  
All of my other complaints/arguments related to the attempt to extend
this case beyond dladm.  Creation of a new, perhaps non-obvious, parsed
language/file format as a generic standard for everyone else to use
starts to get difficult (and probably fails the "obvious" test for fast
tracks.)
    

Erm..  it would be nice not to "threaten" other people's project (like
the libcompoundvar.so.1 one) with a "full ARC case" just because they
want to address a generic problem at the root... ;-(

----

Bye,
Roland


Erm,... yourself!

Full cases are probably appropriate in this case.

The problem is that somehow there seems to be a belief that full cases need to be hard.  Not sure if this is a real problem or a perceived problem.  This is the problem.

Real architects should relish to opportunity to address the problem at the root.  They should not do that as a side-effect of a specific project.

- jek3



--Boundary_(ID_IKEtc9izoYegYp3wum8lFg)-- --Boundary_(ID_UHm5Cl/ORNySjg/uH54hFQ) Content-type: image/gif; name=dilbert20122245080304.gif Content-transfer-encoding: base64 Content-disposition: inline; filename=dilbert20122245080304.gif R0lGODlhWALKAMQAABAQEICAgEVFReLi4pycnCcnJ9vb29PT08HBwXt7e/Dw8KOjo7Kysqur q5OTk2tra/X19YqKilNTU3R0dO3t7fv7+2JiYsrKyltbWzU1Nfj4+Ojo6Lm5uf39/QAAAP// /yH5BAAAAAAALAAAAABYAsoAAAX/oCeOZGmeaKqubOu+cCzPXqF9eK5/CkD/wKBwSCyOLrtP pZLTFIzQqHRKrVqv2GzMltz1tOCwGIrcMR7N53jNbrMAmbh8Tq/b7/i8fs/v+/+AgX4+XF05 X3CCiouMjY6PkHQ+HmU4GxAXCGkeiZGen6ChonRqIhkaS6mqq6ytrq+wsbKztLW2t7i1ATU3 hjhfp7nCw8TFxsfIq7uUORcFBg8BmwUQydbX2NnarAQkGR2+4eLj5OXm5+jp6uviu4W+wODs 8/T19vf458uVExIfBxkg4HBSg0m+gwgTKlTYbUQGgwsjSpxI0ZC7XjgOTHjwoAwwiBVDihxZ b18OAgUc/zwQ0IvgO5IwY8pM0tAUyJk4c4q8mKNCBgETJhz45eOhzqNIJZrM0cDCAwPTMCad SpVdTQ9GdRxYsGDAjgsbdhjgSpZrAw0XynrFYeDCBQ4NhkJgwJUBxA5py9aV16Xt27g8hupQ wEHDAQ5kOcxd26XDVq6VHCNIbJispp5uLzRgEDbHZAYCP2xooJfr2tELKo3lenkHTxwdJkQw YEABUaw3q+rePW6p6AkYMESIyru4cZre7kYYAYBBEwAYdFQQcAJAAx8AsEM1MEmEgA8cSETH AaEUCQChk3An8X0Bs5MALnTndMBDAl8Q5kug8KH8eQPUjbBADgyUMFx/GIwggP9AE6Aw3AGl OIDDMiIQkMRrH3RgASfW3ZbVcSAa51sAAARl4UBPvBTiikld9WECHgiAwAEWCCBPgR609oEB pHVjgVsIXOCBAxRQIJ+F9WGwAAcXeIWABwRcsJxzGea13I+ZdFCBVBl5oCSTXnGHBmxxGNZA BgVcUJt9vlAAQASZTADAgh3wKEF8BnQgQQFBWlBAZ+5FkNoFtmkggQdCcZCBcwPQtQCaQXIw AARoMoDAoZrI6dYDf7rGS08CLABBNR7mxuKpOflGgAU3ucQlqrDC5KJBA0CnQ3oSOAUAfzt0 4IE0OFQAgIQfIAAAVBq8+VV8OBQwgXq/6rCAAK0qu8P/Ax6sZYAHB36w5y+IwgPAgDgI2S2J Bn27Y444GMsYDu6dmCGX6uLQgAdQ4SBBBh8kUMBAAOj4AYbTFSCBBJd9FOvCM/nmQHa2ovgp wxSHNCsOHBzbhZsLbODBmIN9nEMHzirwcHMVdJABBhpA0EutQyULrFYiN9NAEiqz7LJn0X7g gAcc5PAAAEzkN14XFRQw8wcCFPIzr5yWy+y6opL6wdCm5nBnL3rym8MBAGzgwL8f1FrJhBNn SEAAASTgUVFZVyw3QktpYAACeAv2gatz981QcjigZKqxUC2nN7j+aC2BM2h6YMEHGABQQAEP gNODBBNQly/NiYtz5+SVB4um/0Cj55AAekoY7EvSz+bwM6AeCLbLRgV8R5TkBZArge2+HGrb 3kpLVwBdJXLKew4Y4qBS0KX67TzdIiBRwZ4FoAky389nT8/FxVLTxc8CNF3zIR507q2NS2jQ 4AdyEkBAvj1ILgKVnJMztPubf3Cvml7q8HTqx9tB0o7ms/eEpwwwkl8B1uKEDBCgYzh4gNd6 54Hf5YdcAKMLJ1L0roGlrQMSHBqVFKa9ErLDJB1ggPvcxzzgpc2EMCQH9/JDrJFdDQAHw4AA NEY+802gAHwxVr/IloP8JKACHChAwHaQJB00YGk5+GEXnDCBXZytQILZ1+pUl4MdhmZbN/uA 4SrQjf8MeCVpj9PBAXXAF31VUHQEfN3+yCi5/GHICUHDwJhIGMM+9iZ64sCeHweJHIdABEYR KBIHJCAhZ+WAAuPjQfn4IsUOaGADTRMjAKTCOks8gX7/mKTNuhCBTXYBJXCQzpMIoIDphU0B CkhPFx+igQFsqFsDsA8FKuAewRRogSozX4aaxgAFDIAAGTjcoTrzgXi1zD1oWCN4asAYDIEw AyJsHiG36an36IACCOiMILlJSO7xIEAjaIACPBBGHFgAdeSRHEQaJAA0+cBC3Qhf+BbQARzm gDsFgMi2AjqOfOoTg1+o4QBKAQAOYIs58sJBgiZnCttAYIcCulcLC/S4Q+n/U0Y7Mk+ncrCh SkyPQ1jhT4HayVHkvbACCZBAO/lIzm36JgeKCoBAxlnTPpqzXBFIQJQ+QAEi6WAAEcBIBxrQ gCAGICgReJ8lIhCUoARtSVphAF8q4ACtjmMDVK1qCz/AAJ3mYAMJCMAKwdm2BLhVYBd4ahUX wKsKRECt7tsAUt/FAU1cIAFVFQp5OMA2dX7FAbIka9tEhQOk5g9vLn1JAx5wgAd0hqY99WPd EEDGBGwAFS5UUWZN+NPRxpBgGXBABwRwHx7A7SBtLEfKkpAK2i5hdQmprXReJR1WCBAmJqnA AyyAgOq1LrS8Ne3zSqvcEhJMAA8404EwSw8DZKCd/2JsJwIeIEsEmFEHF2ga6PLVgQSgiXLp YQAGdmew9AQgdEwRwOYgQNkprqR61QvLpSb33R0oanL4nVzrONC0DIyVIibZAL8eMAENBERi om2u85gr4eclbwAYyEACQkPdeYSHXWQtSLnKp4PaSeVnQXlnc4bpLGx1y6MYkI1BvoDBftWg MxtqrQAjsKcSRQAC20qtAySQv3ZZ4GBPYPADLPSkDEwgA95EMCAVcN0CNEBRLUlRcissNwqL owIU+N1AFFCkIr2qjaRq2Q6q0QEx25CNXKpAYm+7ZjK7eSAtowAE+GLnm4BZzG0GiZw7AAE7 GwICetaBBvK8Z9j0OR3JG//IAS77WnyEJzuKUUMLoQkO95zNZwD4pxLDIoDEBeAUOMhcF66z J171qygbEJLk7qyD050E1eTYxQ72BY6LRlghS1nAnDYAAHnxlMt987IvGKDE8vFHAxiF2HED xxKhoeHUECkPBzJ2XA3VeGAL9F+adAAcsSjRBxL4XWwml51wD2CHPph2A5q9H6Ja2Yl/ykB2 vAQSCJAoO0dkH7sl5xWA7Ltb5oi0O0dY6XtkzFhYGReJT+Il7qTRidnKQS6Hc2R4FQIlXSi1 m47bj3tNTgLu+bYOlvO7CAiAAlthwJZt7OpatQaMIQmuA2J9gHcdG9m97ckBZDmAC+itzbE9 68z/D6LsvsBhbf1bbbG5QoDDifGNEeTXDzECSdKIgFz5FF4kE6i3PYHEYxaAOrCS5ixBLUAD ehoWAiLQziBD/XGQjOjPFioAqGPQUOVjwHKCJmC3owJNqYnAgXM9MQXgDW8coDRu8nGdCkAo WtR518+y08EQn63U/cqAkTJgAXkYywJBEUzemwnilXygIUOZky/csxawecPqtfamsKVC+pwD klLlRThyv+xbnBnfEFuCuyFiu6VetaIiD8CAPGgIGxKJoHXy+XQOhGMxwJmDU6EJz80CQMQu CNu9//IXRNxEPCg7AKDeNFaDWriMkcpJKm4KowS3H8AeCCzr4ecBdjEu//4DAAsFLK6HAwVy XE3iLReHAxQQbic0MQAxB8zTYewgbPxxABIQFu6BXQUERSMGSlK0C5PQLfVRPQIgGOHRVQQw J+BQI8qTRglSZEzhTRdgARawAKXkPV0AI5UQAd+gA+Hje8xwUQpQRaAFYVv2X9VzXinBFT2B ATdzAeu1JxnwaRuAAfiVARHABEl4MGiSAOBwAdSTAZeBEvwFhSCoEFxoEEkzJveiJA0iDZ5m CNDVfYZkDvmxNLvDesyUBMbCKx3wMEO0ftYhbO+2QRZHUv+yJ6HxMwkieq8mFeVBLvs3IeXn WhGAAA6QABdYbERYOaLoOmFTAK2VgFeziRMyQf8QaB1zlwD/90eFQGgVcDeuhoHrgEVeAAAg EywEmAT1EVE/4UEcwGwdQlSl6FIQ4wOawCk3cS819BVAYwjuMYs2VgljMxglYoTSY09wcD1a 5gsIcGR38jEb0QA6NDKUY2OlFhRFJiQY4D7YggRCUjsMRgCOAQcOMGSXoV4HUwMpho0H4S98 kQGJg02uEzv3gns4ABR6aBPmICQ68jBL5Ti7s4LUWGr15AMQ4C/f1BzdUEvUISFetDcAIA21 ciC9tAv+0A1uFocX8II65h7hIwFe0QEUcn0fkH3+83LBqDwAoADh44nLmIdJYJOllpMbQgIT kHThkDwL8ITw03D2UCD/2rc1ilYAEaVx3JIDyyEhD8MECyWArvVt+7IBRcId/qB+O0BswlRE QxIsAtBCQGgId8kWycg+UaYUgIQXm8EAV0Yc47AhOvAA5gN6Uxk37KeXQ+Em0whuM1cABEQR EVAIhsIv3KE3ThAA1+FqbQSRFdF0ZrArOjCSQoKQFpAA8VgDu7Mv+KKIZ9Uc/0MBEWAbyzEg 24I5Q2OA0zQULvaZ0gFlkzAz4RFjt+kZBMABBwAjDJAxgTg2CoCK/lNB1DEJGKSDXXCcsqFu KjQjDaJyUZk2DnYzErBHVlkPT/J/P6MjyaJjIaNhmVMD/PEz+WIAT3ABwhIqXFEY7biQSGVK /ztwkoMRABtCmRygIeUTUzGSNTCCXTCCeiW5E3+5NmzDT4QpDhviajymAxnWk6aJfNRpXd7T SeRWABTAI4YlPHEpEWUUBynSASghFSuhgY3FMl0Eny7qfeQgJJ/3L8TmkK9IP0/CAMN4gwbQ DZ+WS4/zSwD2lULiHHoScYfjEy9XXGYJolZHAVLxMdtyOKBXTzqwJ6t1pZ8UOPAEXgBgdYH4 AY6jD2kzHQ+QRNOVnvSgAAnQedyBXdPRlXTJHBIgGFO5Oe+mCeeYHS+3KINhYAfwhUlQSndW K1gxOc6RhNgxAW2Kb+5pfcMyEsFFPUokji/kCyWVA8I2AYD1OW2GQ/+phzMC8COTMG57EhSq BaIkUABVOjlxkxDdYDBI5gEdIITX0ndDqYD4ojWRGRGkuZUCEBYa0A0W4iaL90gr1lhziSYG oAGK8g1KmgRookmtJGd3ogAecyLTAUhjmjgDAGUDAjafhky+9Cs+gQHO2g0DEh4EcEkPIyEH wxZPEDS1gpNyNneGMTWmI1/w0jPlkDwcCBQzZqcK0Uq/ZQgaAEuxJB2J1RNkViQC0WiKFjcV oABJB0u6RR4XGw6E1gWFlrETcVPl8mDDV5i6xyED5zLZ8RMOeTADwBUP8y/YEgcBIA+VlXZj UwBixnZQuRBYCZYeMBrvQGwT8CSC0SDdIgD/yboQy6oDxjInSQaB7NQmWSpJaLAeT7BE9/J/ MPJuxyMk/NSp5EEdINg0BqFgsQNJQEGrt/gE9XRjxYKoXRtBKGU7ZtdYUOYVwiY5hFABHnO3 E6Ba8hEjUDZSC/tCCrAADrAAgqGLQEcxKHQAjyeEWTaqhlCq7WKALeNvx0qdpOqK3fBqfqZG YesTBBUSS4sxOTKdFvBZFEAdBzBAFBAeSqQJxDatf7OH52AAAZAr7cRVQtofrNkTE0AlAwAc DrAWc/EqNDIADnBg21ss+UMBAWB1PMhnEeAVEXCFEhC0RHW+GGBUbJG8FoBdHbAAenQW8BIB fFFUvLIBq5J2YVEB/wGAvuprADE1j642ue9QARlWKdq0uc4TXAv8Ey30c0lAuiAqZgVCeNOW BFL0tv9SSgIkAMmpPt7EdruKELUbSs7BABDDCcxTXD6AAYu4Qz5IEVnrwKeCWhOwANHQwDg8 N3UzKh7LhOSwIRg0iM0AJUxTIkERAHfWIMCBUQPyMwxmVQWEQ0/wgD6BdRWBVGKmAOVrCQSQ AGGscVilBAsgGzaorDz6w3KTPARQasmouY0VUwfjAII2ZBLgp6JhAVZ3AHKVK4JxASvBSPIA xruDAbjXqLTmvGuhAMmLAfkCwAdjyCdRQycrLaCkA2W1VC0EwJpgAMBxhXgcAN8GxoAVHP9t CGno6gsUvAMNoJEZgQHpgUmagEwARomneV6vehkHIF6TIyEy2jQinFjnu3TN5SJu7DfJ02bG dAgQuwM2CZv9paB7+4td0pUTVTuBSlZwkDkSwAR0i3oGdiEZlwSQNCBl2WOakCy1Qx0HUqZC +W3CUplRVEHVMzIK+cspYrVOIEz3Ijnhw8fo4BsbQGuvjA4QoQpJpyV0xkaqMLHL7AtXkSaZ cdEYndEavdEc3dEe/dEgHdIiPdIkXdIkfaAYsV1Ry0x0/HrHCh5zwgRPEkY/c2D18W1yMsQq YyPSbLA/yMUhaSGaQlRoIrKqu3Wp9h0/YwF39p546QEQ8IeK80j/bJI6lekuJwyn3nSZE3A2 CT3RIHIVbjDWZM0GhTAAD+AADbARmRvNnOxNKwU5rrheTPSVpymgwaI0HTAAB8ArQihntPGD aRqSA6K66+Icqjtvkag04ZIETiB8puMBFWABrvhk0/emALQDbqJ98+AbEMABkZNaOzWObvzQ RbSxGVux6RGybdR8hWaxFovM6HAVOFTJtn3buJ3bur3bvN3bvv3bwB3cwj3cxD3cpL0A7/VU DVCnkycOQvLJ0JEsCJdEsgRJOvokpkwAOYktaiCK9zgJshxFszsALcQxtZI/58k0rLIBu2MQ 7hEjh5Y7BKI3MDIw47IAY4wmcMhF3uKK/8CzgwRAkFpdCYT8E6czIF+tXNNRmfPGCZxQYw0e jEnkZg8QAbaHUiIgAUm7DsoM1hXzGjwsAGWF3D5sCDg3S7UyVmBzwOuEzfXBIWUAwAZjXmZJ YM5CT230QwYRx9SKNy+hapHTbDoW0NW6ZvKdIRpmOqG2kyIAT0nDO4PbE8RpLfTgMB3RLshC 2stHAP1whbPIATXyFGoERRcwAW7GVAKkxxKQp7B8MOKZEC9+NnJyubjcCylI40HDwgcMFGj9 q6jauBuuDjfs4bzxGgYQvxNAAA/AcM0dDuskLyQjACmOb7KUH8IESYmUWPJgpZuugL6p5L0w NLziJp77Er0XOf8OQCLjBqKHPpc74ATEkixDOEQFxJwH0Jwv3d/y8E43ET5hdg++AckCgAGt kdDBqm9YgTC9kkAZJoFMo8QL2ayz1Ebr9BPUMTywsSFxoLAR4S9cKGZTKd7yED4dC34Zs+fT pmvFK5GEvjAYwsNcrr6u1ej4QeXdMBz8XR7C9OS92JUHIH05UD0KvFGxA7ua4CauXh8H0APy 0g0308HywSzy0UrUoXKZxHrVKHDNhNfh0RpyouRJ0K/44DApIUGh+2s70K1J6TiFEgDaMidh Q3ETt4ogkX8ZAWVDYS44MHgSoTITYN3NsCsaAE2NVeQ9YCkh+pDTBiMHnA+D3u5VkTz/PKIj LZ00EiCYDdIp97Lo09KXPjEs7qNOyUJZt34AtQQHC9AAh2IhCRIAKgQHIAFtBSCEvjgkZmhK 2OL2y7Eg7COg8mG0xKYJ67pEb72ajrNDfdWN3eBqN102scwt+boLeNUVq2h0t86yAx4sBvoP 1Raz4nAvKie7LEt+UGuqNWDXOs6N8lIrjwOSOfATgV4PZqNJ+QIzD4VDFHAv7wJdxuJmookD eYkQTw/1UyH1qS7pJd4YCeIQevOCIlAAizelJOAch9KMOd/d6qsATYkV/8feNdC7G5Id5GKp ImABoUEiYuYMBiAsIzT3SZnFinudlChsYlYrA7IcDm607z0C/8MBAo4HkMDyoam6smjgeddX YYVXAFKq2YXWsi4eAkvhiQALjw/Hw0ExhhiP4xMBKFSQwill8WUCqgZgAzyjWwyAw/GyoBQA xOFyIXgCjkJFJZEcAByoCEyoJMSkKZ7hwXhk9C1KTlJWWl5iZmqevfikVAhgPITFATxGplHY XRigokDYQQAZrNr9qF4g2EVq1GWp0Bp0nCn8oNQNrGxcDKZQCKtodHQY/H5ouO5Yd9i+QqNU HMgqXAwoKMjirlJ8wObGbr4kdjAQLNgj7PQYpx3kFQEgwsKAhwQXyGT4gcBDAw0ZPCBYw+5T ASQpCJQp8CTFBQAyNqFJAKAASRsG2v8VaEDIApmJH+QEMJIgBYSAhxKBbNEIBqScPn8CDSoU Uyd+GkIFkDDzpameQ59CjSr1kryPZ3jc4IfGyJIVHQToYLGwhKkT/qpsyAAAA4CTKjIY8gKA QkoVL8w87ZDhQQVsG3LM4JKCYICaD7JQEAAg2YM5Gi5ImHvTatCdp6ZizqxZalEVCAREkJCM 6eXNpk+jtlQ1DVZPiwqEXbGAYYoNKjEaoEBhQIYMHwYURDHAFM4UoVJEwfDBQsJjHmIP3UDF rocDHQoIeCBBbYGTs7GbYoCC7g0YYqh3EWrZaer27t9/6JziwIQHD5rJKQ1/P/+pq1dcUAUK rWnVQgccBED/wgTpgSOBBxgk0BgAHTCnQhQIVOBBVx9cYMNGKdTQxgMjyCBEAW6QNNpTAwCi wgYtPiBABmAl4NYHDGwngXiDWSAAS0Fg0Ix6jujXn5FH+iTfDDNOMMFH+bGX0z0rOCDQfA/g NV8ACSSAwQRZNoCBUllU4ACX2lUBQWh/RPCLBg98iAICFqUwgAX5pKDAmmAREAkDW04gQQAV KBDAAxiIaQgHcaXQQHoHaGeBjZzBQBkKAeqTVRoVONhbAUupUOZDAAgggwR0fvAVEglYyaFG VBLngQB4fvCZKaIhmSsK62VDyQYERAAonhfcGUGTEUyaQgcEWEoBsIAScUEExmBz/42jCwQQ QLL0cJkAoBMUhgKCCdDawgEBTNBnrUIuK+QGDljzW5sqHMDBMDMQMEGNKGywwD0JRKAiSEpW YMEC09wLZa+ZYJXlBwIIsEIUllrgSAEZjPadALJ+QBAMI8EhxEimdPeSB4zu+k8KIwrJ4Qhg PUREBQ+NgF0FaVmsAyIP3PtwAcMEQioOAkP13wZNIrDABPcSqAgExVSwcJ6yDJhN1EAUmOo5 57TAta668ppJhx+f+FIBGDxE0gioDggAyh8cQPMNyk3gQRYIlB1FzQXs+MkUjow0dHwjmHKe VwkCoBYGDkWMgl6M4rEhE7JmOQEAfUDgoIweWUF2AZZqov9kB42RpBJpUW7CQeJwGAfdjcWh YPkGClRwbyDTwu1AB9K1WW2tDFUAAQckoROcCh1EcDLQALANnEU1zfQVBuig0oECMhojD+sf POBDBdglo4ADRD/13xqkCmB401+z3z4QYTNM1wSRLLDY2VEbMEWcMwAA6g50SSASeKiA6gRw EtUdgHa1YwGhFACcBETtB0JIgAYgULdyoUAEuDrA4iBGCOWgQAI4sFETZHWv5GVBJDKoALms UABzXO0nBBNAAxBWiiJtokcLscp2eja5vu3qciuo0Aq+57+OeSA9zsuQ5FJQN0PUwGoFYF3y mgEWIIgwEskzhUVEwgTJmOY/BCT/wAAWkKX1uS8oA0DAACjTFx9+witRm+Mn5kjHTdzRQJOA nyZgM5hBZAA6GBCAK3jQxBRk4GdQAECCBPCLv7TsDBAwHgq61zOw+HBmGaAaiBoXO9/8Zg4S EIAxxnKyDHoAAtJpFQrIkLWciG6UTXpSU6RmiZqIQUa/6J4rhMCgyUWAAQzIwhYssoEDHIAC X8mAMBEwDCMY7mEJ8SMLOlC3KZjueIE8wMYeNIjGCJMDrrCcMfDQgJhZ4XIPYB0EkJms8lVq Pj6CDS/2AZUB4JN88IlbAwQgiwMw52K06sACBHCxjRjAoCXpDgISeTGHpoQArOSIBX6gAAlk M1UJKMlh/zgiJoNmIJLvIxLqLuHBFWSRI9XRputSkFKX6UcD/bPDO1VghO3hUgUdiZccfvmB CRRAFxcoKB9cCDeV+aNLR/jAbMoIAGOcQxZCYNYFHDYwTTmOAFtKAH5q6ZOFcKBfS/2ASDh5 VAGptGbJoEASr0EzHVSMBBjAHAAkZzkFYAeOKXiBAPT6gVHSx1sj0cAWSWXWF/wiCuKwQUSe WohUjWgE+gzKf7iHAZZsckD2TAMDJoCoP+RDTX8IUgsWIAEHOIWwf2AQAcRkJQZY4A8PsIoB tioKq0riKwmwgAMqQIIItJZWs4HLQ2RAELgkQF+qiG1kNFQfvG1PYh5gRwNGkP+lZU6gYoxC BFiaNNkV8DETIoTjF/gxHCB+YEZ+ddAvhDCCvmGFBEdcgRFi8xcg4tVhFODcCuRBJADIIkYV jEwyCAOBjR1gIQbY6DAQQLJnfMwmMsTqgITZALcozCciKMENsoBYYFByPCejANW+Z4gDKa0A ZPVAbiLxPRCiwAJYMKjUZBpNFdRABU04QHURQIEC4QEvHclHRwqQIAUkoHFDxQMGh1JZAlxs AoTULIXPcAUYkEQ8U5iRhFcwAL5lgAgb2NjFprPikRiPOzYws38v9t000GIABmjAC1uAyXYY 9AdGPsMUVPApIEjkr4mMrgCWEgDXLKColAgvJsi5AkT/WIMgGfXZwuqGl/06wEE70osADmCA V+bpOXWag07BqFm0pkAEBAjniJKhGBzAoAoy6RhJXnCQMnRMonOYpAU8bUuqUJgGJdlIhnNS A2EyQAS38YDDjPA2aK7A0ZWM2Au0MjNPdkQ5kTmDEYEgElQ0wTYsbsEOndOFjsAAmRBJQVP9 E89GXYABVkEjGoTnhD4Y4FXXkBoHmGEvBxFAGvX4nQMgoKZ1ZwCCFTBAxYjggMXQzq+WgDI+ G9CAX3xZRZJ+mCdZ4KCJfI9tyAHwXxbQBFp5CQWJplpHXCIJRl9CBNm4SwpEYtUc62TcH9gv Ao7igR0FchH11cf2QKFoubhE/wMKqB8/mnABmVpAokQ1OGA4RJwGSAdUf/m0yihLYR4EYAEP sEix8Xg2QkACDwtawIWNUAB7mBwCMsWAbiiwgQoMJwMNQMCI8iGCC9SdHSK8AIJMMQgHOcBf DBDY91oau8UkGMq+aUIDAt+Bx7yBAOcwc61MkQ/FOAABIpivk+NJWAJYIPV0ojcafCkuQio9 Xmc4CwtwHsKIPdY4P1uDxDHxZSLxjakZ8OFe/nqi5EbAFQ5qxvfQuveRV2A2WRAh1QKlCojd a78SaJJIR+qIklJiAAyYQgIWgAo8OIABBe26F44g0QaED7YaIiMPVEKBh+Rj8Mg8AKiH3igP WID6bf9Mk30Z82jV2cyGS/hDAwiBjfDOB+TVpdgAEbzABNTDFPFPp+0fqKlGlYld9+xI2WnC FmRUh6yRKZSABDgECpKAM0VGSWQAO3ATCQhG5wWOEqRTCTCTC7Bg/xzP9gHBFeAASWBAgQ0h SfRVvt3gSTxARg3PE2yAjJFAAPQeUKxGBehCG5hcpriGIrCVgNAFDpjCrKRB/ZhVOzCPZ8yF mOgYi/nDBLRBTV0CBZgJAnCAYgxAaKzAFYmEjGyf8q1UYKBVBmwPA/hGYzhABEyBRXSCKWxI TcCGpLwcSf2aIiTPCDwCP6CbIywOCyACkSCB3pSADAhAFyhABiBB3ZAF6Az/SAbAmMqtWfC1 AMMRRwbcmjWcF5T5ENrEhwX0TEdYxCU+B5k4yComCVbBQh3Y4S+IYCZ0AATAETQ2UN3JwtME Xh9UgN1twOyogG5ohQLoxjbKgvXohgL0jNIFXoHEEAugIwUUgxaE4waMoztqQD1eRc+Ao+xF xX8owCgIAKqxniR1HcNJgEQJzhkkWjYMR7kEAn0MX54AAANIx0h0mk8IzAL2kwoAhxjsAagt HzjAhYgBWCslxKuRxEiww6Ed08YIiI1VAsxRAjlUwzsqSx3YAW4JRy1cQBY8xkxinEtcDTm8 wwXYkm6wgDucYRGUgzf0TDhowG4ogxyaQ50wQzfa/4FQVeIkyEfQlEAIelUagWUarcboFEB9 +CCVdeGm4GALCAGqDYQgKIMTqID0bRQqgFWGQBBQFIIxJA8HyIHpaICDnARG6GMIBWI6DcCb mIcLbBLzzNFCnABqvQLiBQbpoQFMhmVm9od83IwAEAAFYIBANKNmkuZ+rAYEZABe3CHTbNYi nBRZWclsuCULyEiWcAA3PeRv+NEV1IlaBA/75QQenM3GNAd3idDPpYzL4ZhcxsEQDsELSEBj LABBUIZBdcDDMeMApldZHkthghcllmZ48oeSpNcD4M15jKZ4qudmrIZDVEm+9BVacqBORQAO LMiKFeQL4Frr3YC+sKQQeP/moS0GU1EBttiAGPjWrNjBAWTlIjAASAUAyDmAQQlA3xiABHhn P03KAASK6ewBDiKABJgVZByIiNKEk7gQDCpnzn1fg67ni3pdWh7AKHXU6bgoJRzECiCA7JWR A3xIj6YfP2AhB6gfAWzLUnpGM9AD48HfCsxZ9TRAM0AA1tlUPbQBASgpA0TSkBapHLpbIggb R3HhfILIDeDAEvRjCQjA/gABBzSXEpjBAtBMBmxER5BAf8oCDZBFAeAkJkjNjU5CBwBqC9hR FV4EeP7EnEiMbVpKgLjCgnHJVh1MK3mLilwAujQJeoFDA3TLVrHKlAYLl5xAbUWqpxoAkQaB v5j/CQPA0aVGarfsywe8C8AMagem5dIlXlfhkLGdkri0VQqojiPEhTBqCHL8F9t8T8dBj3N0 3BeCVwFw0qx9QHW94mwEDgnIAA+8jd58zERlxn+4Y6r4zjW0Zr2hgz3SRLhSwtOYlfWYo02V o7WBYznCaGZgJiZMwYZEgUV8RVvQxMW4At7cKQn4YuYQzucsySMkEm2sAGr+FwmElFp8jHJg xH/hAAGMUsP2oC/2V6zUDACoRL5hIgYYajxQGIWcJLF9JVD8TRWQR3yaTUhRwAsQAR4MAAVU ERQMQVX9GAu8gJBU10YgTnqwFStBWbQajxRaRRQ0QNRMVWBsKxXwbK0e/yNOPGgERFJA1uvW AsW9XsLfLMEWlEYBfkTygE5fZJw0DE5DGEAibYBekCwKFB87nkN1BZw9Kh3EqG0DXU8BFAME cIrrQB2JjesnnAMA1SPgGh//OdiNxahRhIHSkN3K/sQoOUiTrIXVeoCKNIYGmCH/mM5fNFk3 AsD2KMYPaGuCYNhYXQS0htpMbEG++C2/jFWCmMH3NJF0TBpqiNEFTMCMEADVaC3X1uuO0oIm eK0l5MjJiMQU0NZIJENdEQN/lWedDAH3gJKDjS6w/qofqJjHdeEo+dBXOF4LUJNwkBoKXMGK TlhaBoArSlh6bgJY+NwQAEdcxAgwzEFHSFX61v9EBNBrCziIGQCHBAyDEFxATYCQTB0RlPHD rDnYbhhPTUwAw41Ab5Gvxk5AAPPuuzkDAVSofNYrO9AOSDRAj2AUChhAdonJH7qBiySfCrMw m5yQWy5AAvgQAZiO6lxABiwAjoCFT6VB8laC3lbMELBVdB0ASYhQnzIFnmwBZWhHOvUjDPTa GTSByAFVr0QGJ/HSCnSPLlgHt11Mz+wBKvzF7ravVhjANi7AaMivM15R3/6AWmRB+qzA2xEE WIyEi6nFFALBQiDBbHTBHtAOkwVGE9EZJ03STPxu1FhOMnyPBdzhHwBgB4ivNhGO42pGZemU 8JZrILulRCqDmejOpbD/Ui7ICz8MQwWo3wJEANZyyP4MQAA4TJJ1iJdKQvIUQqEdg0GNwPZh Bb/qzy/3wKkMA3DAzhRwLApcjMsEAC86wAP8LhYsGqLmxFc0TmQInjUPhil4qz50wZeZVaJ9 QJDF1hS4bgs0wXxBmsfZTc09VX99zJQBwfccXY/k8dtYIYVhhJe83Q2BnyZo8zM1wws8QZhp gQkQBGzAAJ4sky4kJSL5Rt24Rd2Ioahdh+t0hFU4z8OMDAzIzPl2jgZE0fEYFDykhifHgQBM xPAuJ6M0AYMssSOo4Iqhmox8gAiwA28gwUIQSRX0HSEw2/9NaDNjwv9iDTXNzGJWFwB2Y6+2 /1LiQMcRg8p4wVYFBEC5VBf7MgI2g8RXFJUCNEN1TVp1dd8xya1FtK1W/C6BqojTtWmIpYw+ slcKoNB3LgDgocF15HOzpiE8dWGieUkAwDHl+sRLDUaxCpgTsZju1opimM4fKALllaXjMAmX VEz+dRxKbA8iEGUO6EsCbMcdg5LKAQBZpTZKdXYHw06/8diYKsLf4PAG2MArGpRf1g8cyIPh fMEXYSFJ5IMgV1UJswjIysn1Og4cRqF3TgLPUYAdJsuMgAN2TEEN9IipKbAfYIABsMHKlMd5 nHQR3cGMACoRU4IIFYh0GHCpdd9bp1dc8ICVCPLrWEUgyGETOK6D2f91Kh2qVc2GLlc3e5CB jbRa0XzdBFgHAeBJHIuXEK1AIlGDrHAAB4yIGBiBQDgsEXzBBpSj1CjGgP4GczpzxEQG3DEA dT3HhAZHucXBUskIBUSeH71A4v2wGXTPzeoGFk5qJ3vwcDADxohwGvxB3fxBWW6uCsNlK7HY ho2VSHTAl2GEI4mYGgMcBJZvNh9xt/pBT/AAHCACgC0EWiXrvYju4OAJInzGdNSNPsqBkU30 ZYI1SHSxVyRSwJI4dTCA6jBKxWz1w/Hp6zAALSTa0a1AE0gO5hXEApiVYB7q2l3Y5FSebsT5 94ykZnEBggDn44I3mnnlroLEhPZKm59zrCz/BbQJB3Z0jjG2QHV50hoITH3+FJEsVQVEFgDK QvI4zHZ8wBTEigAkg3/BwBIUVguyBZl6XXHgzQ+QIblWGRBcUWRdnMrUJyp8D9sxhA2oxBVQ 3Q1Y+1rkwqQc2HP4K1SoVthpZwh5wnb3uhjwgCfNjKKtAQcgAB6AkAjwH/7l9Qpo6yWg9ySE Sa+IRLx49+huAFvcgFVsgITIils0AVmUyuy5TakdrMAkiJBwKwxEjHeTBT87Tp3LE3Fwcj93 4YIxAALYiINjwuW1wACI03hEBLtUVTeGD5GGU6VzgI2oQsMaV4X7vIrUi420kZPKQL3sOSvc y6n6fM6/hM0LkwIc/y97enDm9AaVO3taGsgVYW8f5NlyRNfDkEt12DZErAE6oKCVNPVv8fsU eDxQuAKvybMs8ACM3QsiqEhkZA/hlIAszMYTKOHGvJOJ+fucP4WMw9EA2FIdrOgytIw7MINz 14lZPUYCkRi/C4xQroJb0MIqfJcC4GQwuJuMDhrVqDzxmj6wwQ5TkZFs97WMDEMHTMTP9np0 XQfWklqRJQji882IoNV26IZeAYcQd+1NH9WGJKAzv6KvohUiUA3E1J13V0EUdEEgeLBdhPMQ E/7paz9RBFt2NNTkgvr2i79WTn2PQAwoP7sAG/rkiAHF4XUMEEQXOFil6AWGXLmgTa/w//+E iUQACDgFcH2DI3lYMmTCB8eD925O5lnBADzxFygoDh5H7ALwcH6wzmLJjEoJnqonU5Fqt9yu 9wsOi8fksjjgKWhimsziI5nAFEms+Y7P6/d8PdpTAoOEcHGR9aFRkLbWJQHAGAMBINABUVDQ wJGQ06HgQRCDkITwkQGqIeDR8PFQsEEBezjnERDTQNoXikODy+EBkHE50GDE1CGQ8YGQFixw UQAFY1BgUPEQ/cEAHVUhYFFGZWWXS15ufo4OtPhDUBBsMFcnm05fb38P8xdoIsBQeJhoXRcH AuZ9OKbmAwdFVTBAQJShGAwCAFYJiADDEoYPEX4B+LgqBp1aHyr/FNh4ToGCH50gVKjQgQuE hy1fZowCIaaUhzshiQlXZRwfAw0WNFgZY0NReDAOhIxxABKFQhcWIFhTdYHWrQ00GEBqgkEW Awi2MlCggYPOOYaOaN0gZQDTKBtIDchqdMCHA1v7dq0mQ+05NAljVCBAANcHOlcM4nsMOTIZ fTIEWJbAM2DhLj5jkNUJAYG/HxoMHlh5YO4GuAo4MHjNAG6MDgcoQJ0rOTceoI37dPzl4Y2g JL+gWPCAURoAXB1SWAFQjaEVK89AwVgGzzl1Ij5iLPBwAMbvNOFZWtZCscKE6Z9Ksa8CgAMA 69kAgCVHGFKHBwIOFAjEmFC6DUhgbpSZ/4BAggkCpMhmBT4IITq8CYgHd181oNcHEGSQAQMc ZAAAXM5ZlwJKFQSzgD8HdNBBVh1ZUAgCdEhExBIDMPBAcCteUMUDhzTgASm+TDDAAAJIBINJ EmjxnQIbMIAGAReswdcCaARwQYIGeJDAEdANJlBJBTDwAQbdBehYhHqspWaBB0bw0UdCwKBZ Z23eiedP01F4B0FSLACAbYgU8I0E7tBChSJMPZCMFluSVFJESbUHA5C48FgFSTwukYEcszFh 0jd/BtqUB2QyQcRTENAiw3JgbtbBBBm0IhyaeeoxADa3RnYgBLD8qlOduw5LbBQTpllGAwA4 gIIEYsHxgnePSP+QQQtVWMAAqxwBMEAsqHrQHQwSJPDrozH4cuoGKqQCCo8M8CDbSwaZ5Cki kHwn6Az0HVGEYYT+egAAwpWTHxMEPPCUrcWSQYCuC9dz4BbCPkwxnsfyUYEDSVhGgwIFJNcU CYZq+AC3H1ySxXdyZgiVB0vGgAFwxIn6AY/WrRoABKk4UEFwDSSEwAhj/mBSlzBYEC5FPHkC Kb9GRwofcSDjF+YHKLQChcIVe1GBBSxvnU7Es8FCZ4N2go12ZBf30QkMDqhSwL7LHCBAQhCU hwY8y0RwgQFs7uXyDxbErRVFlMCgbjH0mqCIfFLat1cCCRQQ7qBGd+BODO3wJEm9Thv/JsCy BCxAkee5FExnRBEgHU9vaW9hgATIvr6H2Kk/AM/EtBPIYrFr77HAXDYL8LK4BVSQwn2AG8Gj Yt+iBMME0cJQ9yEdAGC0SSj5l0QA108NwNTHNIppeREUwNPJxfPb9MgxnGcO6iVRK2tyWu/+ A474x1/FPogoUBYKwEV3+4vMBgJwtjv9Tg+hW8BUcDCAZbDgAMdZQswE5a9kbGkB8mITEQ4X vel9YD0ruVsBnAEX+H3AAEnoEhocQAEDhE42oUDOz9xRgAPoLFoQMEAwEIAbHlXOULJoxezw ID8TBKABEViaPAr4Awc0DYp+6B8bBNCKDAiKgFS8xwSQtKsF/+bBP9Mx2nqsYDQ4YTAGx4EA HQBwiRNicAZC4c8P0LAS7XhADtJbC4+WpIBUwMdhH9gEeQIGR1XMbzogXGHg3ne8GEwugXlI ohTuV0DEdJEPEbvArCZgAShwcZPpMFL6hiXGPFCAGMH7wQEQsw8IfA0qBMgCB5jFLALoZzRQ cR5fssCAhrlGLxSYJSGacEsC4IYJF+BAhgZAAAcEogMcIICHGLBMbP4AAYJpCgP+xsmqXfKJ XZyA6UhZhogN4BIJyABTRolOcywAjGHc0xHjiU8uWDIKmNzfAyqXzzNYMRSJoQ888XGA8qDN AQolVioDClEt7JMJ/cTfPyM6hohpYP91ZsqM2QbEgHM+rAJNfNhDMYpSdThonK6jYgBEmlIp dHJZWmHEQe8xAAzc81YXACgq7XkHorzyB6ekkwIooABwagipn4oETyrgxqPSRCVUhQVa7KUB BeSEqBTgSSeoelSkMsIoBgjAPCqQ1aMqIAtF7YCd0KoSpGYhrVVl6unEyU9yUtEBPuWaFhRg gGpaEwE0lIJSIxQxCkiAAwllEF4fAwEJrJFiUqTYSb8wjQZkIBAbKEDTOoCBj1wBNxAIQJwm 0AEGCIBlBHEriOKUDEA9R7QBaAccP4ILBZTsI6iVT9REKwcgEUAAqL2jIuK0gHUiiQEZUF4Q PCIwOMw2CV//6sNEf1DR3S1gfWCIwCwvAMoERGB0UnyABThojAgU9k7qvIQLPPrYx1igoRRD mGWBeodx8XUiVcBN3aIJAOiViQbBXA6Q9qE0J0zODaQwQAQkByLyXiBmE0iAVmzTDRUwQGPO fPDk5jNPwmKPIso7wOq4tIANYEoiVFjmAQJwnAA4MBuSO855o1nUSsZXJHqF4gEyQElUwUXG IgmAABagPEQgwALO+AEFBLCSJ+EpYj/ewEzY8NEBTWBgFbPAMn8qjp1yQQED0ABcTiQBaq0l zRNBX6WQA5UN+EKh8sEgtWRagB/AKQodecoBCouBPEeCAxUwwJdLBQVMUUoU/muZ/8O29BSq rTSvLYUiKhq9BQRsJKQwWMB5c8wEBDxAIgzokmJP1aaITYN4Dinbju/hgKk9DAIYmCyYgyJm MBCBsHCGgR2tVhgLNMqVSngJBBhAghgYMQoJeEQMshUVDcSkAy7ggiNAvQV9IS4HOGiXEuJC qR/wiJ7hnDRFewxF8XKhA1eBAQYuQIGNHEACh5aCBiSQnACQQt1THqiGmskBQrva3I/R39bi je08XZYMcHrIBKo7OQc0O1xYjAIR4DiCKkSj2TneBFh45N4SLG4LyRODJ+yHnGkAQgPzuWSv xc2lVwV5MeguIN0o2QECSEAvmtiPAbwmhg1kIDwPuJsF5v86c175Wz2WEQB8CY6PC9CMYgOQ QNLVtPAxhFYCdQMXDDaR8eI9gLsrhKM5E5Aj+nTE1h6XgQoI0ACaeMPaHkgyF1juqUR0CQkA CNi+IgGAc/LoaZKeeXbxJwEuS6EBAoDHfAPgBjJInYIfgJFCdp5qfz9jXBbYYpZ1swEBXL1N A+hrPcOMsWakeQRwUSMFjvOAmCB7lkz7Afa8Ax5m110kwWFCw0m+ezFkwEQngQGyFTHFJhSf mdoi2KtpXmkqDvewz3bnAiwsQjHwxwENkAMKMO0mf0/DAhjIAC5ueg/FJvxWpa9Y1sNAB/ps CSNUQAoaLFCaYHDASQQZ/A8EYCL/QIJkbLIJNCQJskYBJ3QBZEYQc5EC69UFOlMAXXUMxQMk zUdUHNJVMOc5BrB+ArVS8nIIh7c7qEBuoYYBniYB9BUGARMBzvJSdhd+gCBuCBAACDRwo4cO OgOBxFJ1uQYh7wcGcyY4ANABb7MPOUImQTMd1LBHP8B1yiAdQXJHNFg2AMB1acZzxFEFrgAz VvgFD2cFSyJsawEk3NUBFsCFsuMZj+RIsnYH8gMBreBeK0GCu+MfsxQFGqCGHEI0IohWxvYr VvVAl8Bkt3IgHDABERAA4mVTn5cbqNCDwxJ6H9gmQvgFB5AAPmEAqAVehaVMMEABC2BeBEAB 1oANpLMX/2bSiAGwRi8GFk6AAWkmARggGyeANKa4TQkgg1LgACvQiGTyGVGkeB0QAcCYAKhW EgkQDRvwAM6DRGHyHbWIARbwEHe4OxHQSFGwH94VDLQYDO4VR3EUJ8BhBQWAAAOQjHlyIIxH A3WDFOhnD/uhh8QSWb1oMfgVU/soPwsgaNhVc1TUDVanBQeAAQjQDvARR8GQBuN1A3EzOqTT iAtGADqQfBBCZYL2bjlYIA9Qj8MCWvWmcPq4jyklPwowfJKDg9i4O4EkAD3YAAGAMB3jEvLi aWChAQ+gjDHwcDknk+zob+tUjQWQIfJoDx4JNhMQaQ5FkiWJUfKDbBjXXNDHJ/+blHMs+AEE EADvlgNMkJOTFW9JtgnUdIw6+BhiU1ZYgmXPd5QfOSzXd1+o55QmGSbtYBAsGU/MggFvM3UK IVLYEgUaowCLSJDs5W9z0ACSxZEEgpRb04lxiWsoVSROKT/VEXACh5foFJOa2JXs8Hf58JmA cgERwAB9iVgDpRStAAD4t5gDgjtgQ1L4GBeiEWvMcguTmAuYmEmEFFHyIwpxMieZSUoKYCap 0JeqGAV9xARAIgDDxZszGAibsGUiZJT1MF8L9Zx0IT0JcAupcQClhkVuuQe6uT8RIJIBJT9o lVUasFXCSUrHliP4xwjWIGBfeF4elgCpcCTgh5EDhQD/dXMJK9KautGYW6NpYIAAGZAAk0gB EWB+EtKU+NQBC6oHBrAAjJgASySeapJEBsAf10mVQIhPvpAGJ4QMaQCNpaYxXAhHxDMsEVMB JgaPA5obBVoxXaN4UyAB/PkDBnCQyymbYECeLfkAQSoxCzCLCeAApOMAEyABAWB31CcZ8sMD kwBHWeCe6KQNXWcFXiYAAXAAd5GfeqFWKlEaFDCViHiYnvF0ZnkONloxRiKeCKCYmVgtoYAB booeERpPCrCJZkBBE9BuFLWV/gMBDqCnYVOXXzIN4ZGlpCRx/0NVMDAAWykBFhABtiYSXqim YKgF1ZkOabihqJQAyBJ6PCoF/xHQHfsRCCI6BXyKTn6aqPOGlT/AAS+pOd7DoWGiMdf4HyHK BzeCGBygqcMSqXnAg7uCltLwiGxJD8n6OoOanCcoMY23F8mxpHkwpLQjq2TwZKhqC0dHMsWq G/ITMAUwAZdwjQE5BhrwcBj3EQKQnXeSADDVBAMgpfMzqgNyIBsQWv80gTQaGdDaRUZipL5n BGDqrhaAm0IKq+9ZpO16XmHwAG+gFQqRo+VaNVJHKADCrmEQWdBAAaVRF5PTHwuziBIzXkln AdCYeVbor5TzRY4FdfdAnAe7NRtWBp14AQngoxnLMA9rlRPQsFLAaS3oENbIASt4mg4yDArQ AILyqP8/ACj1KEOuQiyjtgW05gBByp3KqnlWt1HxCImSUXWJWiwpZgYYgAEEsJEDsAATMK9c sK20EwG1ugV8MwaLCHf0tqubwUJAxiFY+rFgYF6IYFW+F13DspdcUHWfyWzU+iAHwkIl6maD 4qzpsGRUdIRc90nmNAGNiEtL2gANABuEMACBdEJFYV4Wtq97KpcRFU1iAAH2ugWAErolYYNA CxnyQxFw0VmOWrhfcD7Ucglw+B3gWiAWsJRM4GmjGgCSC51JcgEBYGiyAKro0ACEhz880KRJ YKLH5Q4g4jIcYr4j0AMh5QYD4KqvGrsQdQFkFxc3yB+L6ACjE025RDrRhHb/FkAtk8ABL/gA BPC69OC7IfIBnVUCU9uGmDAAECBtUXCIu/KMXGBOo3qsQOmp7fAxwVK2kRFrVJSgQEAkhxAw CAATh2EfGsDCLAwBFyBNDuCvyuuw7xtQabiTo8JEk/AA+VkAUgRhaUA8EgCwAfAaR1bA9iA/ QgcMk7AGDBwKjHKpadZoHiO9A9IcLktU2jQQ3Puy++AfhNBkmFuz9bAfOUw7/3mDqJJsEwE5 UgDD0evFZlC3tDNhXuCgsaMYdPoD+dkZEZSC45V5DgIBcUsAOgHFPYqFhJBj54O2ZNDCYoB5 epDB/QaGAWMALRAI2WsO1pDEaVsAElBiWPsByqKp/x0QQRNAAHMMDkKLTkRmwVikjP8pC0Ym BVCFAQ1gehprbuxGuNGHB8SVBeDEA1qcC6vEKBzypOdJqei4Bw5gmrsKhsbITh6cuejwyLdC EV6MBPsgCsX6gj3VvHTsyqT0ZMYcPbPCBNqQPgTAJwaAdhwQzfz6WEhgh8OrfcwwAY7RKTt4 PujKAQnygi3HBRJnJoAxBgowmv4LZZ3qP1lyTAI7l3twhhbXd1BBKkzgYGihadnMDuVMSv8p kkFgOiNsC5ebJGEatao8yD7xVCgMrHwwOVlyaLZsDi0QNzlGBXg7QoawXRLAfRcwAFZGVb6y AQNwABxwoRjgDXyjATvg0P9JAQ2eJBucPNFgoAAOupNbEgfmFFq2VruW4U59UMf4M2HGLApE 6UrzoSBqRDTHuDoR0L4GvA604aCEsBC2kcg/ICtc4B9J4itUUQgGMLJuqg0RqwXjwgUtmyQW GmtOehKzmAEPtogRENRrNAE0bCD+FjQPIQDn98FXvQdG4gCpOxMU0KRcVzdOpwWjaLtBa8Mo dQEXcTYGgAIHIC+KZb4cwtrM5KCWqHQJcSLsAQDrCsxxCAzV6DAeMwHlh75xAlsZcKkRgAAU IKVEcJF8vcvH0A8GAVpdC6Y6uQWtMTho3J9guEOG4nnXLNpiwNAMLQCEBxNc4KG5CdJ9igIw JAX/TDaL1egAENzC1Ad0LX0QNtghr+Gxx03Hm1UIX+OuwYABS4QAtTGId8EBxNDcwZABMAJO 1dEFyrUFsQZebZs+DWABiZEF7vw3rZEAmCrUnafB+1ABqI0Bc2HV7e0F9zayRm3dYpBTcw27 kTnRDnZoD3ABR21l7q3ZZxkmS0tpVbngWlBaCADcRGXbjjDZc0Q5WiAXdAMMkxh6gnIA/DFj o1Yk3yRDSBEaRnZeGPRgMd4UQ6eGNHPjOD5mGICzUkABRUfW972PaRgvY1DBBH4dFUFVMbHX zxZgSMOLuaCJwVAMXKdUS+tJ3R3iiteJ+OYGp5EaOqMVqlqxEPhkzLzZ/1b4T/5BN+VR53au BZW4QugsExaQ511Q1gHFgwpmlgEwt8ENCSQKH/es4GUQNJk81EC+btogAe3Qg89gAEozZtao 5wsAgMlFUkw9wDLCBaVmyYGwoygAB6IU2qxeBgNgAW4F1GWgHuQK20Iu7hoiWffG0zI1zgQi Pw7GiAEQAU+Mz2HAAwawAVpl7B++M1qAAUtAXLTOyk3QTlkoemBQAbZomFYoAj8sAmTL3u2u BZtbATBWqmRAJH0e2ziuWzkBJUtuNbzLy5xoxAnVOlBeBpYwxa95Du1gd1vJODwdWRuqlQRw 1B3fXdlNz1aoAUVRAVaxlmWM8V6giN7R0HtL6v9hUOv55Oo5ueu2ALn0HiaI9ABwou/BDskP +hL5igeMJQUBEx4LkAFSGrdNFQVYomIEMAGySeWI0/SnCYaloSGkEe5JL6RG82PxLlFV/wVR j0+ubpB5HsCGuRkUcQD7/KuJ3gTERRUenU4vwzpbkIaBsABYGSt3MRNE2wW1xZMoP6UDdatE DIAWj/Tl4BTdREqMKIrqlU6C7wWEH08/zqxiMJqKDwnKQorKQqb7DgZtwNsQ/xhtsASWMO+U mneTzAQQYI06pFsbSnmCUO7SXAI6LgqHeiqrbgY5Fwf+q+60E716EAG0T+t+HlPtVwZD/9ql vxkoOYaILvxf8CGUfwf/C7EGyNawILA433dgHZmSlMV0iOMMKk0qFkR2z1z7PzAoDHg8l09F 4ggUOBYESVPwFDTC61UzGCiQEgnhE7Fgy+YzmtaRRNIqzWbCcf8IxWKmQt/7KoRJwAbf4I9D Rg9WxcBCwsMEhhWhZApRFQ1DRAPKhwKAR97kx4TAAMJFZCiWBNnHQ0bQDpRYm8+GxAKERoeD LEkOUhfJBGJMKiGREYlBYwLGwqYUFaoxkoMFIEZbQ4bE0UQvdbgZw3V2w4WBQm6KBoTC+8YF g0PChMVDd6jdHah4UIUeEhwKBAhAyl8aCBMcSDBnagvEUgQi4MOQoIGgCcEQoqmEalcBABka /9jw1I9QhZAFBDwQxLGGgyMdMgQIokBAMAtHfBx4UIIBBAlzVjhbhIHDATEkSRyQsOklFmQ7 NwgoYNVCwGiWxEWQwMAKBQwjDBRog2AC1LQqJhhwIMBggVUCJDyoK4ClXQyACFzYUKEBuEH7 8ARUqyDCBEAUPlwAgOOP2isDarqKUCCDo8T2EkcgwMBA4Q0PNkYO4jEFAg8CEggAIKjTp8KD EAAYAEF26RUAGARh4JMTzh8cHnRwN0CArAUSWE54cA8nh5o6JCTN/UMqCbeCBhTYqXWaMQwC IlSnICCHAAIDDDi1zvEBB+QDGiRAoGBDxA0b3qnzQSAwH4PFVloEDv8YYEADD1hxgQCLPfCL eyq0dRwDBzTAyj8IjmLBUxHScFp2BaRQABSwnTTIAwIApAFupTXm0g8JLMDUCT8oNwIKEQx1 UQ0RIBCHChHQ4iElRezEQAEPJGBBAT18588Bd0kwwGIBTJDASssl6QKRxrCWwAcIVHClGQpc 4MADBVQniYAnQmXBKkc8AAV3//HQpQ33SEBBXwIYQEMFEAxwAX0WWBAAB8u0SORpFfBZQAMU EJBBFyYu6kZrAnCzpnWTXvrBGtVhAgQ9gqj3Hwk+1kDAM6OlcAGHeH6AHQkMiKcTO1NsJY4G F2RwVAdNLbABixBssACcf8pKSASOHXBBBQv/oOUDBBQYwMECFK0SwQWqTtLmp+JwsNyMyi1p gQMUWRDBYkRqgIEEGSBwwHELIMDBRM0lEIADC3AAYwUWtLvsaY154oEnAFRqUrhlQnpBXw1z lIAENgX3AatAyIiAOx/YmyqA2X6QwJoaSAAjo0ZG0dVcM0ahK3jhdOUAhD7E5wBpy6Lx7gEZ CBBdvDHEUE9djvBLAFIbcbAUm3cMmNs1CDTwDWkUTABABDFHZkBNAVjgMzeHZtJXzTQ8wCme p1HQANttM6CHpZIg8IqsBAjQIQ0GYJCCA0P58MQCCgSLqhgAMoBWAC6TgAGA7tG6QAH9Wqbs kxyNawDeKxwAQXz4/5StcxmwQpCNKwnQsy+rHCBApdYkdKuP026mlUB902jQANKmA+IhA2E8 EFMLmZumuKynaXAg8gYMgELczBYgQgM554ZAAQPXwCDECGCACKACHHHbAQ40cAACFjTAxVOw YkwyI/GiHSGtbqHjq3cwvxQfAS2Oi0+DYowAOhpigIAHHCEAvHHDABIgPDeAyzoLwMBOKMEL upDAAu9TSwQYsAELUAlXZ1gC6AoGgBGSEAA5aB4fOjCXgizAetaBAKSAUIEBZuM8P1AApDTw Fbc8YCIFqkc+PjCAijHhPyY4YNpU9gEIOEA8AlBc5RBiKAe4UAHbY4wNB4CBwhxAYjrrgP8F DBCBBFxgIBfEggIe9K3YeZEaDXiibHDwAb0tjjf9iUwSBsABDBxgIC4kwac4MC2CSWOJBzgk IkHDCYYRggIAOKN1KiCAQdZhDlj5wRA30SwEEMBrjliACUhEggQ9QFmz8luXaPWB4RyhAb+I ojhuAkrc9CQFfPwAVfQwAEe0DoArkIAGCEilKdHBZNwLEButE4OdKCA6AlhBkiZAF2uYMi1D nBUBBPGAP4YPCAaIFSEtsTZ5uA1ujBwEAwBggHXgKQKyU4EBa/mDAX7mA3oRgNMQlgF3smEM xLtJNVOWjA8gKU0McpL9EOKrb6hghg1JAV0OEIDaaI9pvhTOBCT/magLSEB6ZoDPGvnRRmM8 AIIXeMQEkJUAW/GCAxcowCVLk6APZMClgtzEwBYgnVoIoJfWKZgHMHAwhC3saXx4AABW8kQ8 vQgIHZjAAXQKBAYkQB090YACngWxA1AgBy0QAM1S0IFx/a94SuwKxpLaLliGwwHDOOFZMGA+ CGLRHhFYgAA4eFEhiO8CCZgBVXwqhASEoWkizc3oGJBVDrQLAhOZA4LqgoEGOIAAn/OHjNiz urMwxiC+WUJhfUABCVwWfoU8nrWSx7xz7kEKVNTPH62DQwANwK0bPEBnSAWmCjSitK3gwFPG mqLfEHKgBsCMKKr3skIihGJz6MkDFtAD/wTQJYgfcEBtOrABBIggoHtNgAEI0DcDkOMpxrIB CQgAyYWElDC5MU8AqqkBCvTRrQizAGsWcIEBjHQQa6gtJAjlgKeyagELIIBXgAABV4XTCgOI QACEFGEHWAGFdDBAbUCnwrKGCQMwFRMGNohKGqTLsjfwbeKisD/yEdesAwVVQPyy3F2Joygf aIcPgjEZNghArnrhi291BgELvGtGCpgaIG0lFOX45Yo/KFB7jaoWBr2NBLuUq+mskVcrxKQ0 5hHF9jARvRZ/wIIK3pPOgJpPDxT1nWdIZwM4wAAOeNQ6zWHK19higwZhwLspMN0MhoxiTTDk CSQYYAiViAQOdP85V8wVhyQnm4IKKGAAfWRAtuihq8ScTLAA/KYGvJcUAoApTKvxGgbkyp5e EiC0gklmaRggAVfawACLebCOdpAUqpYG0RbYAAUGkAGIldoXaP6BMdNcSEoPhLEMyMBiLOyG ANCkHvGtmwS+SROU2WKIKKbwBXRa5+tiOowqGE6iB6oBt/qGaWw1hixN6QRAVLYBmMirRSo4 7r0ygo4HiMP/+gYodOs2ym5GCF5loAIFGOQZoxyBLTydCvFCALwRIIsCSK2CwAbhTg3mGwBG VCLWumHDvqRNBhKAMqaUUgKfas4FFMC1ceP1ICpAtLIHOgBAJJDCM5b4HoRNHnbUbDL/khaN Hni01+t4xnsfGO1SAhBBvu3UP8V+9WEJdLY3mI40aRSEB9PiI452VQEup4cKDoChHxj6464T yQQyAIBokzwhBfBzlw5wd4weruMHyGoHqgoEu3l3AGtP4kCtlhjTZSWh4kCAAM7HkwCIJRIV uBMChrR0GliQXxTAzy2funJREK8G0TF4fydBsakXpwZICsNEEGKhTooPAxlXELbIIEgVSEsI FhhxymhM3ZXIQtpowPAXekyABb63SYVInObVILBSlDm26eVwClgA9LSoUpCIieC7U5EgjgGq Kw3AjY6WmIAgA/AmtgDKBqLUBRZ8Luw2i/4eGlgaryERCP8+//ThhcKYWITQGATFSJoTAAe0 kEDv9YGxSEDjmBaNAdLC1V0AFYB4JYYDpJ4/QIC8AEQFtMM7UEBlQdkPrIECHQjjAAGEUYsF 7FtuqBIuxdwbOF442M2A0YBjXZbItAIk+dI36c0F5ADHaRHeQED/AMHuGZZ7lUZJ/UtqXcFo wSAdIEYEwMsXRBdgMABYldSMHAB4KQAFDEQGAEJBRFgCCIkF2JDb0YD8LZKUpQEF+ZIKzcUq 1IOhCEkDGBAQBNMRHAh1ycjfVQuCXOEF8dboeYgM+kD4hYKQdFEZWM01+M/mBQujNdED8Isy zFQJgFMKcBwQaA/q5YZetAUDjMoVmP+ZMQQFCcpdUi0Vy2TABmZiI9yDoVxJGXGAE8hAV+kN 8/3UowGElQXACVmgGUAAANAMBLDTskzSFuyHOtwGq0CVUxFAKdGXtDjCctihHPiWx7nY1DGi DVJDACgB+6VAlEhATVwAmelMtBhKhEnYFyAGnEgHgtTALgmBKDJhHEIFBpzNAjDALv0iCawU NaTRLyxjjEHK5qzAvAzAflyWtzwdaSnbrgyEBbRQChifGVzAJ2QASE4AQZbGP9oIAfwaLDSC 4IwBIH3ebVxBBByTQIVjDTTiJExABuEGBJzRgawAkdFhIxjAdlEW0lQat7CHeuhFi4TaBTDf ArQjHehfZAT/Ze+0gqcFJDWM1mV1wIUoVyQ6GScwmFntigGkSEhUJEeWgQMUgH4YwN+BzijY CD1Yn1gxTlAkIkxGoOMoGrKNozEcyvmlgI+IRlTIJJ6wAAusWQyRAzcIAAMEAHzo4kTQTpYk zr3oYgNQRE2NYmmwRqKAyRjhHWr03yRQxWUpwnEpSwcoj35swbNIzURggKuxokVOwxhawAi1 GQemgAXszV6506KIgEZcQVPcAh0gSs4xEwNQAHjYpCRYwH88BQYolkheQaOBjkRVwHA40V08 wHIKwN/px9OdYQBk2QIYQK9YQ5LUBSDsC+xkXWTMzKhowJ0FQbhRg2kyYvIVVjmu/yFeGMoD dMZy6qAA4OVeXuR9aVBJ9KMZ5NW9jM9IylQB8CBFnOMcWVRHAJ8iqszlMQlLQIhzEoL5oIz5 tAJdpsCB+RIH4J8KUEBc0FXokFk3cWZknGQZ7ZbTBcGD4Scb1kADHAUYLEkOMKMQIKGBAuOu UA8AsIGYwOHBCUEFZMBl+EwERGhkNEZsZYsacQRyFtf3QCfWTEBoheggiA2MLEkFeM3y9UbV LUtVBkFXQKAZmCBqYCgywadacOH5NQe6ZEFzGOYe5Kd/aEQDFECVocHonGgMPtoSlU8R6CYd cAd66oIvDcAj+YCYbilCXFxyjhIPuILfkOlR6QiE4JV+OP/Bvn2TldYo9tHABfyHcaaK6bQa rYpXLa4cobxnE0aGFnHMDP2gCnQAXgHrGYBiDShHW/hmGoSFhaoFiJRAa4iEgjjpbq4S3ewV DJHmjZGC4GHBj9DBNyJeBEEAAsxLDTIqOVrEwHDhn6hqEOQSAInXu84FSO4XPlRWrdIqL7QI pukqg2KS1PTL0jAAYEAMoRCsvdmbCIgXq7RaWYhmDSiAPVgackyCebTOREwGi2KBsSZRkoLV AaBCWlonQTRDDoJOlOJfEixABhDr4uhlEASTou6fEnGUFz6FqO7BGC0gUzQBBESYECjAsAHQ AtgpDaRhZvZmAGxfCvQrjcbs1Xj/mEGsBgC4Qo8RxErgZgL4zAQQRAbgFVJFWLNWgAFcTYV0 w4FRISw4wqK4hdWUXkcGYPChws0cwFOMrBCkmi4iAOb40irwhM/ElO/RJBb4Yqdel0gK20bk rBmEYDtQwBUeanZww9JeAYPArANp64ekoRWs6iXAbf7BmhDoVNGWqwbMwTlQQAA82OoEQAXE QBoZgL9gWvwBAAQ1a9OSCBe6VUXuAQXc635tgOxSG1JMJx00YBtGSVKVYYUZYxY8z+aJQsX4 gI4kyZEujsvWQICm21TAiToWBltpl5z9R+8c2IE1rIF1UhrKlX/2mNxNgEDmDaD6gAGAp85g ZRDo1Avy/4Eu+uu18pWryZAK+JZlaEIa4JVbhhcAEC4avGpz3AWWzMtB0cEEGO2G0hi5SsCj UisCJWO5QqIvuYVJZmIBiMXf8QcIQgBZOCYEjGSg9IQcHa6VhSMsMchqKME+zYVlRABz3MI+ rQJeKcdw8EJSnafnMkVizFAS4gn+Dh78Xq8QAIa/Vm3RVLEVm+UVZ3FzFE1zbLEVYwAVZLEY 18VffcByCMnWQvEZNMCMWANeYS4QWJHaRsaz0gZMfYY5/asQcIBjpNo2XZTdYJKVLMcdlBBI SulQXcY/FkRlnWFvakpIWPBMvgENOx5VcMBfEYABXADH8MZnNJPH0FdSLEAFHP/SFiiCGXtA SnEg5+SVGFwdkbSaECAYuwQIHJuBgFDxGHNxI+yyL18xIHjxL9dFWQgRAmBaGR4xAGdHxR5n q6bSo/nKkupIHj8pC4rIRVXAJnBh62CiBawZOIezOCMM0zorX2aOVqSd3PKvajAwFlDA15rM vtSyh7BjuHRtAChzkGhoVMZO9KoAbioLD5uQMfSdY+2BQgATAD0rqJRlEdCdHgfBGgojkdga DeDv3PiWHhzAOHf0OCuML9HK7UkdIkRDMgoNluBrrVYWvrJ0qwnNSwuNTBfBScu0Td+0AOVA lNgGeXUF7orD6lELXkVAtf4ZxKJBm/xzCgwXqPDxMw//gtnVxxJfAaUdwEmm3BzT7K4or7Q2 b0SfYGuApAQkQDkLIEsAl2BKh97BoEd6tFvnE0gvtBJBbrxAp6Mt6RfktV7vNV/3tV+nml8H 9hckVQ9EnhBhQDm6s1o0AF1kwoOWYymhREtMMXlWtmVfNmZntmZvdkE0x/MQkKn9dJmw7Cdk IqsYbBkZ2BjBiSsWATaH9KOVz2eIrPMGAQzBL8FKbmmkRAbkj2D+xgawpRC0dUdLwFC5dVxz rzJ0RQBrhT5DxQN4QNbY0/qdRVVkNUJoAHftsGfMR1GnwDd9Nw0IyFuXt3mft2oEKAVA3hoq NiHgE3rfwQS2YXyQx93WNhBY/6p7p0VKTAAzotXTCbd9uvVamndyH+4GVNbKRcP/go4rtKzH 5JXXiNIX9a4ZHzUWuCdlczaHd7iHW7ZhfyIClPUZRGl8yzeJQ8WzNoWUMi8HNzAABADb8O1z o4SUEhMDTq/QKipxj7NlGDh2m/OLIQGGmvS+fDiSJ3l5UqY77cSgWAY/x7JO3Ib9uQFjzy8D +XP0aiIeZcCJu3aKvwRD90p0s9mLnwEHeEBDaMoEhPkg9DcN/GgU2O+Ae/SPl/eBe+nCFfkU fLmfe3TkiA/1zAD5cBBUykp8XEbV2gYadAAF2AoGzCxSi+53PXUH9rnTtMZb53kbGsx4NCne 1sFWuP85SlxGYkTCG+mBBsiLEHC0RxMApiN3kHOfor0DYwyMkSu5rnO4K2fHyXzAHtoNcexV AzjNK1oEq5xDzA2KPKiveHhCAYi3f1D6RZlOacBGPiHVps86rSfpCDFpNXOgQchKSjxR34ZJ BnRurOb3cYczdgE5bBuXodhiJDA46DwQanSHEGUthnvIAmx6u+fT9BqDVFb6tQe8tiM3ll8w eLDjBoe6D3hYgDoAl7hHSugEIrxUMChB0AY8XE8UvMv1QBGAve0NQ92YX3pIE6kArKdIBKgx kaTGnxeBsk4ctfuStW8Nwnt8OO/3gaKCtlkFWuL3D2hKb+oFqfNBlCYJ02D/mEtkQ8d3dIzz fDhzurgyxfIsSHUwLlSsvAroUfZ2SY8XMnoPvM3jabVbuji4erZT/Zr5PJKiAoNIHYRAPA1o AAAEcIRcPFdl3wKTQF1EfUcvgNuvmdVD85CLI7oSidcr9fWAs3Gf96Fj3a4afGSwvdMkvFvD /aLONw3YfQXiQtLbeJKsCQwNReDbROF7QKGGvHLHbMpHSOM7vgqMfRFounm36dOmfWkYADjj ZnlzvlYLFuiDNwBoig5L+x6okFM8RZT+T+rH8eq/O55zu5jzpeJ7vuzXPO27DuSvfrbfoJZv XgDoPUfYvgeA/FuHPYEs/uebRBo0xuYMSr8jhFD9/zFETUtiCEEHgADgjWTpAZForiXQfXAs z3Rt33g0XvinFZ5Mb0gsxggWo3LJlB1YDyBr6sE0h4tSgcHper/gsHhMLoMxD7N6DQ5AVdSS g02vmzGegqanEBUIgIGCg4EWHg4LiQuEjI2Oj4wZHhODAn8EAgKQDnBUGJ1xIwAOkKWmp4MS Oz0/J6SosLGBGBmytremCSwCoKFBuI+GvsPExcbHyMnKy8wmeny9zdLT1NXW1yQ8OK3Y3d7f 4OHi4+Tl4M84febr7O3T2jfc7vP09SYd+PgEEgIYCPn5KETIFIECwIMIO1z4p5DhQQMBAiTs QEDixIsY8yEIYCDjxAgWIP9GDNDAYAcBDyYaQGDyYEWP+SAylElxZMSOCCz0c3hwY0eYQIMK HUq0qNGjSJMqXcq0qdOnUIdSEFALQQoLByUVEJCnpUeu+MAidOOhQUKxT93wDFrgAQJnBlFO VHvWQ9C3FvGeNIGgwQlLHiIkpBu1sOHDiBMrXsy4seO5BTioEnABgEWFHlJ20EEA30AMPykE EBDAIAIgAU57uJyvABCs+AQKGGhXtAAJZjsEIDCwtAULF/Rl6jzYAwKIDR7gzvf5Z8yyejd7 wLpbuKYOBriGRMi1gYQHHSPkLa1xNT69aPGpMkjBdfF/uwcKxuddwtrH+PPr38+/v/+kBUQg AXX/EURQwHMZlATQA0EAAIABBjjIy4MEiKCJhQddkFkGAJhkiGsjdKBKBkD8MwKIAHDlgg7K BfbeWw16EByDHD4IUAodRNdBARl04IEA0rUYwQVAZBDcQSpydaAhHZEIUHToGYcAAsEZEsCR cxnnYx5ACOYXiLn9J+aYZJZp5plEGafleXblw+CJFv3YQQMCJKflWymJlR4+hlzAGT5ytmdX dX5JFMScmXXAIAJcwUfcQWq9hVWhPgJJZ5gnYZCjeWHZJWejunVGGJIy6macXwUlWl5e5nFF ApBEkiABlgDRlUcHFHzaYXasoenrr8AGKyxUABCQgUQIENCACwAZgIQI/0Ny2mk+n7a5ZwcO JuuBBJtaBBajKhgKpF5q+TXCrC+ah5eGvcbmQWc6uienudsGNypAYukFAG6lrsqmRI1OieVG kjALqZZyVootkMM27PDDEEcsIm4pAsCopvjQhOuP7OJ63Hobc6tnm/nQSwIFBqjKFQUAJEip nORqaYCAt44lpbqrdUzBcfkQ4IFpnGrIbcIzq3LgvfmI5VdnhlhwIEAdd7uXS5ctarOJDMuZ 4nm0Suz112CHXVhlgh1ngY35ONjARuYVAIB3MvpsQU7v7vUPqPmoQsCUDArmdgM6yJiolQrH zIFrFFDAoaIM4xMpzhL9rcoFF2jCD5ukBVCiwv+IK+6CGwU90Phec0vSkYaqAqQ2ApIEt6cO czfAIQWYYGlr1kAaIp6Lcont++/ABz8RkVul2LVqI1hgUIUjaEYWp4FLR3KuT2N3aGUnANGB JNNNV7h5amF/QmfpPY6secwnihcKbJKQIKCwqlBsjiIwSvJe3D8KhHM9yz/fnhR4Ux7MMqrb wU8hUhCAQRImvAY68IEQWwj/MsQSgOxsgvcpys56MsGMTAlfQrmgBSt4lwxe5AL8y0CPhte1 ieyMVtu5SwshSMMa2vCG/XGLw0bwqKbwBodADKIQh0hEpFSniEhMohKXyMQmOvGJUIyiFKdI xSpa8YpYzKIWt4imEAAAOw== --Boundary_(ID_UHm5Cl/ORNySjg/uH54hFQ)-- From Sebastien.Roy@Sun.COM Fri Jun 13 16:49:24 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5DNnOxe022915 for ; Fri, 13 Jun 2008 16:49:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5DNnOTx038364 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Jun 2008 17:49:24 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F00609E6C0600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 16:49:24 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F00DYJE693G40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 16:49:21 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5DNnLxA016975 for ; Fri, 13 Jun 2008 23:49:21 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2F00801E296B00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Jun 2008 17:49:21 -0600 (MDT) Received: from [192.168.1.5] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2F00M6XE5OZZ30@mail-amer.sun.com>; Fri, 13 Jun 2008 17:49:01 -0600 (MDT) Date: Fri, 13 Jun 2008 19:48:59 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <4852D5AD.8060400@sun.com> Sender: Sebastien.Roy@Sun.COM To: Joseph Kowalski Cc: John Plocher , John Leser , Darren Reed , psarc-ext Message-id: <1213400939.4770.79.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <4852A4F2.7000505@Sun.Com> <4852D5AD.8060400@sun.com> Status: RO Content-Length: 996 On Fri, 2008-06-13 at 10:16 -1000, Joseph Kowalski wrote: > OK. I derail. ? I asked you and others to stop the discussion and wait for the updated spec. It is impossible to moderate a fast-track review when people (including PSARC members) ignore the moderator/case owner. > BTW: I said *either* this is a "one-off" *or* it needs significant > discussion. My suggestion was that rather than polishing this > particular piece of teak, the project team would probably do themselves > the best by just making this a "one off" and not trying to pass their > particular brand of Kool-Aid. It's a one-off. The original spec mentions that other utilities written by the same project team may use the same format in the future (as opposed to some other random format for the sake of confusion and randomness). That text will be removed in the updated spec, since people interpreted it as meaning that other tools have to use this format, which isn't the intent. Can we move on now? -Seb From sacadmin Fri Jun 13 18:35:22 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5E1ZMrb026227 for ; Fri, 13 Jun 2008 18:35:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5E1ZIcK002650; Fri, 13 Jun 2008 18:35:19 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F00M11J2V5800@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 18:35:19 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F006COJ2U7BE0@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jun 2008 18:35:19 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5E1ZIYg721472; Fri, 13 Jun 2008 18:35:18 -0700 (PDT) Date: Fri, 13 Jun 2008 15:38:04 -1000 From: Joseph Kowalski Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <1213400939.4770.79.camel@seb> To: Sebastien Roy Cc: John Plocher , John Leser , Darren Reed , psarc-members@sun.com Message-id: <485320FC.7000704@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <4852A4F2.7000505@Sun.Com> <4852D5AD.8060400@sun.com> <1213400939.4770.79.camel@seb> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 2374 Reduced distribution. Sebastien Roy wrote: > On Fri, 2008-06-13 at 10:16 -1000, Joseph Kowalski wrote: > >> OK. I derail. >> > > ? I asked you and others to stop the discussion and wait for the > updated spec. It is impossible to moderate a fast-track review when > people (including PSARC members) ignore the moderator/case owner. > And I sent an apology about "not reading to the end of the mail-trail" .... > Sebastien Roy wrote: >> On Fri, 2008-06-13 at 10:19 -0700, Garrett D'Amore wrote: >> >>> That said, if, as a one-off solution, there is a desire to dump more >>> information at once, I don't see a problem with inventing a special >>> format for it. >>> >> >> Great, then please end this discussion and wait for the updated spec. >> >> -Seb >> > > Before you chastise me, I'm sorry I didn't follow the "best practice" > of reading the whole mail-trail. > > That said, I doubt I could of resisted the "easy to parse" comment. :-) > > - jek3 Besides, this is still in "waiting fast-track" state. Perhaps it should be "waiting need spec"? Of course, this is at the discretion of the sponsor. As a fine point, if you are willing to actually move this to "waiting need spec", then any derail is a syntax error - there isn't anything to review. Its sorta like a little kid asking for a "do over". >> BTW: I said *either* this is a "one-off" *or* it needs significant >> discussion. My suggestion was that rather than polishing this >> particular piece of teak, the project team would probably do themselves >> the best by just making this a "one off" and not trying to pass their >> particular brand of Kool-Aid. >> > > It's a one-off. The original spec mentions that other utilities written > by the same project team may use the same format in the future (as > opposed to some other random format for the sake of confusion and > randomness). That text will be removed in the updated spec, since > people interpreted it as meaning that other tools have to use this > format, which isn't the intent. Can we move on now? > Great, but that's we have review. The original said "guidelines". The project team then retracted the word "guidelines", but defended this as a generalized solution. There was clear divergence between the project team and the reviewers. Please, don't rewrite history. - jek3 From sacadmin Fri Jun 13 18:49:51 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5E1noXJ026293 for ; Fri, 13 Jun 2008 18:49:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5E1nomV004828 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Fri, 13 Jun 2008 18:49:50 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F00J01JR2E100@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 13 Jun 2008 18:49:50 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F00DVHJR23O60@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 13 Jun 2008 18:49:50 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5E1nodD006920 for ; Sat, 14 Jun 2008 01:49:50 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2F00601JP9AF00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-members@sun.com (ORCPT psarc-members@sun.com); Fri, 13 Jun 2008 19:49:49 -0600 (MDT) Received: from [192.168.1.5] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2F00CKIJQZ1D60@mail-amer.sun.com>; Fri, 13 Jun 2008 19:49:48 -0600 (MDT) Date: Fri, 13 Jun 2008 21:49:46 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <485320FC.7000704@sun.com> Sender: Sebastien.Roy@Sun.COM To: Joseph Kowalski Cc: John Plocher , John Leser , Darren Reed , psarc-members@Sun.COM Message-id: <1213408186.4770.101.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <4852A4F2.7000505@Sun.Com> <4852D5AD.8060400@sun.com> <1213400939.4770.79.camel@seb> <485320FC.7000704@sun.com> Status: RO Content-Length: 2445 On Fri, 2008-06-13 at 15:38 -1000, Joseph Kowalski wrote: > Reduced distribution. > > > Sebastien Roy wrote: > > On Fri, 2008-06-13 at 10:16 -1000, Joseph Kowalski wrote: > > > >> OK. I derail. > >> > > > > ? I asked you and others to stop the discussion and wait for the > > updated spec. It is impossible to moderate a fast-track review when > > people (including PSARC members) ignore the moderator/case owner. > > > > And I sent an apology about "not reading to the end of the mail-trail" .... Ah, I see. It is indeed hard to get to the end of the mail-trail when it's over 80 messages long. I'm obviously guilty of the exact same thing. Sorry for having been short. > Besides, this is still in "waiting fast-track" state. Perhaps it should > be "waiting need spec"? Fixed. > > Of course, this is at the discretion of the sponsor. > > As a fine point, if you are willing to actually move this to "waiting > need spec", then any derail is a syntax error - there isn't anything to > review. Its sorta like a little kid asking for a "do over". "Waiting need spec" was the intent, sorry for not having updated the IAM file. Meem stated that he and John were updating the spec and were going to re-submit it. I just updated the IAM file. > >> BTW: I said *either* this is a "one-off" *or* it needs significant > >> discussion. My suggestion was that rather than polishing this > >> particular piece of teak, the project team would probably do themselves > >> the best by just making this a "one off" and not trying to pass their > >> particular brand of Kool-Aid. > >> > > > > It's a one-off. The original spec mentions that other utilities written > > by the same project team may use the same format in the future (as > > opposed to some other random format for the sake of confusion and > > randomness). That text will be removed in the updated spec, since > > people interpreted it as meaning that other tools have to use this > > format, which isn't the intent. Can we move on now? > > > > > Great, but that's we have review. > > The original said "guidelines". The project team then retracted the > word "guidelines", but defended this as a generalized solution. There > was clear divergence between the project team and the reviewers. > > Please, don't rewrite history. A spec is forthcoming which will make history (real or interpreted) irrelevant. Have a nice weekend, -Seb From Sebastien.Roy@sun.com Fri Jun 13 18:55:51 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5E1toA6026631 for ; Fri, 13 Jun 2008 18:55:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5E1tiXd024885 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 14 Jun 2008 09:55:49 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2F00G0DK0XHX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 19:55:45 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2F00CDIK0WQF40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 19:55:44 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5E1tieI007815 for ; Sat, 14 Jun 2008 01:55:44 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2F00901JY3VJ00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Jun 2008 19:55:44 -0600 (MDT) Received: from [192.168.1.5] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2F00CIXK0U1D70@mail-amer.sun.com>; Fri, 13 Jun 2008 19:55:43 -0600 (MDT) Date: Fri, 13 Jun 2008 21:55:41 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/374 dladm parseable output In-reply-to: <1213400939.4770.79.camel@seb> Sender: Sebastien.Roy@sun.com To: Joseph Kowalski Cc: John Plocher , psarc-ext , Darren Reed , John Leser Message-id: <1213408541.4770.108.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18512.45269.518979.218519@gargle.gargle.HOWL> <48512928.6000600@Sun.Com> <4851475C.1090403@sun.com> <1213286645.1150.6.camel@strat> <485170D5.6080300@sun.com> <485183EF.9040809@Sun.COM> <48519D02.90902@sun.com> <4851BD64.4060405@sun.com> <4851E87B.9070302@sun.com> <4851EAC9.90602@sun.com> <20080613034712.GA2735@Sun.COM> <48520357.4030006@sun.com> <4852122B.9020409@Sun.COM> <4852A4F2.7000505@Sun.Com> <4852D5AD.8060400@sun.com> <1213400939.4770.79.camel@seb> Status: RO Content-Length: 619 On Fri, 2008-06-13 at 19:48 -0400, Sebastien Roy wrote: > On Fri, 2008-06-13 at 10:16 -1000, Joseph Kowalski wrote: > > OK. I derail. > > ? I asked you and others to stop the discussion and wait for the > updated spec. It is impossible to moderate a fast-track review when > people (including PSARC members) ignore the moderator/case owner. An update on the status of the case, since email messages seem to be getting crossed, leading to some confusion: The case is currently in "waiting need spec" state, and is still a fast-track. I had forgotten to update the IAM file to reflect that, my apologies. -Seb From Sebastien.Roy@sun.com Tue Jun 17 18:54:09 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5I1s92A017016 for ; Tue, 17 Jun 2008 18:54:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5I1s8p0061389 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Jun 2008 19:54:08 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2M00E0FYM80Q00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Jun 2008 18:54:08 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2M003P7YM7ZME0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Jun 2008 18:54:07 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5I1s7Jr015299 for ; Wed, 18 Jun 2008 01:54:07 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2M00B01YJU2P00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Jun 2008 19:54:07 -0600 (MDT) Received: from [192.168.1.5] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2M008JJYM6TN90@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Jun 2008 19:54:07 -0600 (MDT) Date: Tue, 17 Jun 2008 21:54:05 -0400 From: Sebastien Roy Subject: PSARC 2008/374 dladm parseable output (updated spec) Sender: Sebastien.Roy@sun.com To: psarc-ext Cc: John Leser , Peter Memishian Message-id: <1213754045.27298.19.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6232 The project team has addressed the concerns raised during the initial discussion and produced an updated specification which I've placed in the materials directory. It's also included below. Changes made: * Made it clear that this case is specific to the dladm command * Field separator is now ':' instead of '|' * Escaping of field separator is only done if multiple fields are requested * Clarified why a space was not used as a field separator * Added proposed man page changes including examples The timer for this case has been reset and will expire on June 24th, 2008. Overview ======== This case proposes to revise the parsable output format for dladm(1M) to be both robust and easy to parse. Stability level is Committed. Release Binding is Minor. Background ========== In general, it's helpful for building administrative scripts as well as test cases that there be some way to cause commands to issue output in a format that is stable and easy for scripts to parse. While dladm(1M) currently provides a parsable output mode, it is not that easy to parse, especially from a shell: # dladm show-link -p LINK="e1000g0" CLASS="phys" MTU="1500" STATE="up" OVER="" LINK="e1000g1" CLASS="phys" MTU="1500" STATE="unknown" OVER="" LINK="e1000g2" CLASS="phys" MTU="1500" STATE="unknown" OVER="" LINK="e1000g3" CLASS="phys" MTU="1500" STATE="unknown" OVER="" Although one might think that "eval" could be used in the shell to access the set of values one line at a time, this has major pitfalls: * Each eval runs the risk possibly clobbering variables already in use by the script. This means that any time a new field is added, there is small but very real potential to break any script that happened to use that field name as a local variable. * Use of eval presents a significant security risk: any command where a non-privileged user might gain control over any field's value makes eval as root (say, in an admin script) unsafe. Proposal ======== We propose that parsable output employ a simple field separator scheme similar to what is already used by "zoneadm list -p": $ zoneadm list -p 0:global:running:/::native:shared Further, we propose that the existing "-o" switch (which is used to enumerate fields to display) be required in parsable output mode. This ensure that we will be able to add new fields in the future without potentially breaking existing scripts. Note: * Fields with no value will be shown as being empty (see the example below), rather than "-" or "--", as might be used in normal output. * As before, headers will be omitted in parsable output mode. * Since it's possible that a field value could contain a literal ":", parsable output will escape literal ":" as "\:", and literal "\" as "\\". Escaping will be done only when multiple values are requested via the -o option, allowing singletons to be used directly via var=`dladm ...`. As it happens, this escape format is already handled automatically by the "read" and "while read" shell constructs, ensuring that parsing remains simple when multiple values are requested. Please refer to the examples in the proposed manual page changes. Output format examples: # dladm show-link -o link,over,state LINK OVER STATE e1000g0 -- up e1000g1 -- unknown e1000g2 -- unknown e1000g3 -- unknown # dladm show-link -p dladm: output field list (-o) required in parsable output mode # dladm show-link -p -o link,over,state e1000g0::up e1000g1::unknown e1000g2::unknown e1000g3::unknown Note that this is a change to a Committed interface, but it is a relatively safe change. The Solaris 10 parsable output format was not usable and was already modified in Nevada build 83 to the format described in the Background section. Changing the format again doesn't break anything new, and the project team is aware of the existing consumers of this format since they needed to be altered in build 83. Note also that space (" ") as a separator is not compatible with null representation of empty field values. Shell read(1) treats sequential whitespace characters as a single separator. Man Page Changes ================ Under all usages for: -p, --parsable Change text to: Displays output using a stable machine-parsable format. The -o option is required with -p. Refer to "Parsable Output Format" for more information. Under "Parsable Output Format", replace the text with the following: (somewhat lifted from the zoneadm man page): Many dladm subcommands have an option that displays output in a machine-parsable format. The output format is one or more lines of colon (":") delimited fields. Possible fields are specific to the subcommand used and are listed under the entry for the corresponding -o option. Output includes only those fields requested via the -o option, in the order requested. When multiple fields are requested, any literal ":" characters will be escaped by a backslash ("\") before being output. Similarly, literal backslash characters will also be escaped ("\\"). This escape format is parsable by using shell read(1) functions with the environment variable IFS=: (see Example 11). Note that escaping is not done when only a single field is requested. Under EXAMPLES, add: Example 10, Using parsable output to capture a single field This example saves the mtu of link net0 to a variable named "mtu". # mtu=`dladm show-link -p -o mtu net0` Example 11, Using parsable output to iterate over links in a script This example script prints the state of each link on the system. # dladm show-link -p -o link,state | while IFS=: read link state; do print "Link $link is in state $state" done From Sebastien.Roy@sun.com Tue Jun 24 19:45:18 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5P2jHuh006979 for ; Tue, 24 Jun 2008 19:45:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5P2jHON001271 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 24 Jun 2008 20:45:17 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2Z00F03ZNG4E00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 24 Jun 2008 19:45:16 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2Z00D7QZNF0210@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 24 Jun 2008 19:45:16 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5P2jFh3019425 for ; Wed, 25 Jun 2008 02:45:15 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2Z00F01ZG9SU00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 24 Jun 2008 20:45:15 -0600 (MDT) Received: from [192.168.1.5] ([71.174.191.147]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2Z00IQFZNE2I70@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 24 Jun 2008 20:45:15 -0600 (MDT) Date: Tue, 24 Jun 2008 22:45:13 -0400 From: Sebastien Roy Subject: Re: PSARC 2008/374 dladm parseable output (updated spec) In-reply-to: <1213754045.27298.19.camel@seb> Sender: Sebastien.Roy@sun.com To: psarc-ext Cc: John Leser , Peter Memishian Message-id: <1214361913.849.6.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1213754045.27298.19.camel@seb> Status: RO Content-Length: 247 On Tue, 2008-06-17 at 21:54 -0400, Sebastien Roy wrote: > The timer for this case has been reset and will expire on June 24th, > 2008. The timer has expired and there have been no comments on the updated spec. This case is now approved. -Seb