machine-readable --query-ip-configuration [patch] (2nd attempt)

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 10:25 PM, Daniel Barlow <dan at telent.net> wrote:
>> ipv6.address=2a01:4c8:1b:eb13:2dbf:b045:8a94:88fa/64
>> ipv6.gateway=2a01:4c8:1b:eb13:40dc:ba5f:4d43:d4c
>> ipv6.dns0=2a01:4c8:f000:1::1
>> ipv6.dns1= 2a01:4c8:f000:1::2
>> mtu=1500
>
>
> That seems like a simple-enough change (and makes it much easier to do a
> hacky parser if you don't mind using the `eval` shell builtin).  I guess you
> would want the right hand side to be quoted if it contains spaces or shell
> special characters?  I don't know offhand if any of the programs is likely
> to produce output with special characters in it. so I may be worrying
> prematurely there.
>

Maybe not in mbimcli yet, but in mmcli we do have commands to read SMS
contents. I wouldn't want an SMS containing $(rm -rf /) to be
evaluated... Some processing would be needed to avoid those
situations.

>>I've seen other attempts to do this using e.g.
>>
>> JSON formatted output, but I never liked that for integration of CLIs
>> in shell scripts.
>
>
> Yes, I considered and rejected JSON (and its brother YAML) for the same
> reason.  Shell-friendliness implies something line-based, imo
>
>>
>> And also, there has to be a way of querying which would be the
>> possible output fields that a command may generate, so that when
>> you're developing based on the CLI outputs, you can know in advance
>> which fields you may receive as output without needing to look at the
>> source code. Something like:
>>
>> $ mbimcli --query-ip-configuration --machine-readable-help
>
>
> I was going to go a bit more low-ceremony here, and embed the metadata
> fields in with the data.  So you might get something like
>
> _fields=ipv6,ipv4
> ipv6._fields=address,gateway,dns,mtu
> ipv6.address=2a01:4c8:1b:eb13:2dbf:b045:8a94:88fa/64
> ipv6.gateway=2a01:4c8:1b:eb13:40dc:ba5f:4d43:d4c
> ipv6.dns=2a01:4c8:f000:1::1
> ipv6.dns= 2a01:4c8:f000:1::2
> ipv6.mtu=1500
> ipv4._fields=address
> ipv4.address=10.43.0.1
>
> Would that work for your use case?

I don't think it's the same thing. What I want to know is the full
list of fields that may ever be returned by a command without actually
running the command.

-- 
Aleksander
https://aleksander.es