On Thu, Jun 12, 2008 at 08:58:10PM -0700, Garrett D'Amore wrote: > 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?
Fair enough. But then, network configuration has a long history of being scripted around. I could conceivably agree that some areas of the system should not be scripted with shells, say. But this one strikes me as not such an area of the system. > 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. You're inviting Roland to comment :) > Given that this is the case, how useful is the ability to process this > data in some kind of tabular format? Well, I'm not in love with the tabular format myself. I think the existing variable=quoted-value scheme is slightly flawed, namely in that the quoting scheme is deficient. It's also imperfect in that some shells execute loop bodies in pipes in sub-shells, but this is still useful. > 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). Yes, that's fine too: first use dladm to list links, then per-link, per-prop to query properties. This requires lots of fork()/exec()s, but, sure -- ksh93 fans can always add plugins to speed things up. > 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!) Maybe, but I don't think dladm's output is so structured. (And one might argue that with ksh93 as our preferred shell then maybe we should have options to output ksh93 compound variable syntax, which would address most of your comments on structured data. Roland?) Nico --
