Not a good idea. Imagine that you invoke some program A that in turn invokes a coreutils program B. Imagine that A has been written before today (in other words, it is not aware of the STDOUT_JSON technique). Since A and B inherit the STDOUT_JSON environment variable, A will receive JSON. But it is not expecting this, so it will probably crash.
Thanks for that answer, that lead me to learn and understand more about standard streams and file descriptors than I ever cared to before! That's a good thing. :)
So then, what about this approach: since the de-facto standard streams are STDIN, STDOUT and STDERR using file descriptors 0, 1 and 2, respectively, are there three more reserved numbers (I couldn't find any in my google-glance) that could be used for, say, JSONIN, JSONOUT and JSONERR?
I think the heart of the matter is: unless it becomes part of the POSIX standard, is there any hope on agreeing on an informal "UNIX philosophy" sort of approach that would allow coreutils and shell built-ins to accept and pass structured responses in any kind of object form?
