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
