Half-baked idea: Standard machine readable output for command line programs

The thing is, you can never predict which command outputs you're going to need to consume programatically. Even if you have control over the codebase, it might not be desirable because of time-burn to make it so that your commandline outputs in a uniform machine-readable way.

I think another approach is to use robust, good tools to parse human readable output (assuming it is reasonably consistent as many unix commands are, for instance).

There is a great tool for TCL environments called "Expect". You can use that to send/parse commmands in the shell or ssh, ftp, even over serial ports, etc. There are sophisticated capabilities for regex-based matching, and the syntax is nicely compact. There are also ways to fork tasks so that multiple command/response sessions can be done in parallel.

I really wish that something like "Expect" existed in .NET or Java. It was nice to have it as a tool.

Hmm, doesn't Microsoft's PowerShell do this? (Chain programs together, where the transport is flattened C# objects).

It's a cool idea. Though with vanilla text you can work with partial output (imagine having to buffer something huge and useless until some marshaling layer coughs up the whole object -- with text, you don't always need to wait for everything to come across to start processing).

Take a look at:

https://github.com/benbernard/RecordStream

It solves this problem by providing adapters that transform the output of a program into JSON, and then tools that can be chained together to manipulate the JSON. It is quite powerful.

I would be nice if this was done in terms of MIME Types. Perhaps similar to the "Accept" header in HTTP (though in this case the invoker is telling the program (aka server) what types it would like).

Of course this only solves the parsing problem, not the semantic one.

Hm... in this case, we'll still need adapter scripts that transform interfaces among each other, and they'd be more complicated (but also more flexible) than awk.