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
