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
