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