

Half-baked idea: Standard machine readable output for command line programs - sciurus
http://rwmj.wordpress.com/2011/07/25/half-baked-idea-standard-machine-readable-output-for-command-line-programs/

======
angdis
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.

------
kabdib
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).

~~~
jpitz
PowerShell can certainly output in vanilla text, if needed.

------
influx
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.

------
bsaunder
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.

------
inportb
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.

