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
