Hacker News new | past | comments | ask | show | jobs | submit login
*nix command line apps should have a –json output flag (thomashunter.name)
4 points by tlhunter on June 7, 2012 | hide | past | favorite | 9 comments



It seems like someone who runs enough pings to warrant this kind of parsing would be better served writing a service which does nothing but ping stuff. Then they can use whatever encoding method they want rather than trying to retrofit such things onto existing tools which are for humans.

It seems people want to wrap things and parse them rather than making the same basic library calls themselves. Note the "inspiration" part of this post: the author started parsing the output of iwlist instead of just making the requisite calls directly.

Oh, and don't derail this with a discussion of suid-ness required for raw sockets (ping) or whatever magic ioctls that an iwlist-alike would require. This applies to other things which can run as a normal user, too.


Perhaps my biggest shortcoming is not knowing how to make these library calls. I only write scripted code (node.js, PHP, etc.) and haven't done anything with binary libraries.

Also, I write a lot of apps which I release under the BSD license, and generally shy away from touching anyone else's binary libraries for fear of catching the GPL.


Or just pipe the output into a filter that outputs the json for you.


Exactly.

Now I have a question: Are there such things as shell meta commands?

For example, if I try to run some CLI thing called `foo`, the shell (or a shell wrapper) first looks to see if the complete invocation has an argument `--json` and if so converts the actually executed command to

    foo | some-json-formatter "foo"
Basically, can a shell rewrite a command-line call, and how hackable is this?

If so then one could write a script that catalogs assorted other CLI apps and runs a formatter for the things it knows about, avoiding having to add yet another feature to countless existing CLI programs.


There's no Job Security in that! You need to rearchitect the entire system to add in protocol support for the flavor-of-the-moment each time it changes.


The article uses JSON as an example, and goes on to say that any data exchange format would work. XML could become the standard as it is easily converted into different data storage languages without the need to write output specific filters.


That would require an externally located filter which changes each time the output changes.


The "What if the output changes?" argument doesn't hold water in my books. If the command supported JSON internally, then it can still change its JSON output. Either way, you have to handle it. If you're managing the filter yourself, then you can handle the change in the program's output while keeping the output of the filter unchanged.

Now, which is going to be easier to test with a new input scheme: the filter that only does one thing, or your program?


A filter is an added level of processing and complexity. Why take data being used in the app, convert it into a human readable format, just to have it parsed with regex and made readable by another program?

Now, which is going to be more convenient: Rewrite a regular expression or grab a different data node? Personally I would rather have the data format change than have rebuild a complex parser.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: