XML Output: libxo - provide single API to output TXT, XML, JSON and HTML

[Oliver Pinter]

On 8/14/14, Warner Losh <imp at bsdimp.com> wrote:
>
> On Aug 14, 2014, at 6:47 AM, John Baldwin <jhb at freebsd.org> wrote:
>
>>>> Marking the binary with a libxo-specific note tells the caller that
>>>> the binary is capable of rendering its output in a non-traditional
>>>> style and gives the caller a means of triggering those styles of
>>>> output.  In the libxo-enabled world, I see this as vital information
>>>> the caller needs to initialize the environment in which the command
>>>> will be run.  Isn't this exactly the sort of information ELF targets
>>>> for note sections?
>>>
>>> How binary format has any relevance for an application level feature ?
>>> What would you do with the binaries which permissions are 'r-s--x--x',
>>> which is not unexpected for the tools which gather system information
>>> and have to access things like /dev/mem ?
>>>
>>> You removed and did not answered a crusial question, which is a litmus
>>> test for your proposal.  Namely, how presence of the proposed note in
>>> the binary is different from DT_NEEDED tag for your library ?
>>
>> Yes, checking DT_NEEDED for libxo.so is the first thing I thought of as
>> well.
>> It is equivalent to 'ldd foo | grep libxo'.
>
> Doesn't work for static binaries, nor for cases where libxo is linked in by
> a
> library indirectly, nor for when the command is a shell script that may
> invoke a command that supports this output, nor for a python script that
> implements this output, etc.
>
> My question for people advocating this method: Why not require all commands
> that generate this kind of output to support a standard command line option
> that causes the command to print nothing and return 0 if it supports
> reporting,
> or anything else if it doesn't (return 0 with output, or return non-zero
> with or without
> output). This would handle the more complicated implementation issues with
> using
> DT_NEEDED and/or the ELF note, be more in line with how things are
> traditionally
> done, and offer greater flexibility of implementation.
>
> Warner

What's about extending standard file descriptors?
Example by:
0: stdin
1: stdout
2: stderr
N: extended stdin
N+1: extended stdout
N+2: extended stderr

If the program can not open fd [0-2], then in fallback case can try to
open fd [N-N+2].

>