Rethinking fsinfo()

Posted Aug 27, 2020 12:08 UTC (Thu) by zyga (subscriber, #81533)
In reply to: Rethinking fsinfo() by flussence
Parent article: Rethinking fsinfo()

We are not talking about configuration files but about kernel-userspace interfaces. If you need comments, just describe it like any other data. It's not something you will edit by hand. In addition, current syntax does not support comments so I don't quite know if you are confusing this with something else or if I'm missing your point.

As for parsing, please show me a correct /proc/self/mountinfo parser in shell. I'll wait. As another poster commented, jq handles that for shell scripts in a single-line correct and simple manner. The moment we step out of custom formats the kernel forces on us, the moment we start to have really rich set of tools for processing data.

And it doesn't have to be JSON. It should just not be ad-hoc, per-file convention with custom, brittle parser.

Rethinking fsinfo()

Posted Aug 27, 2020 13:10 UTC (Thu) by kpfleming (subscriber, #23250) [Link] (1 responses)

YAML is a superset of JSON, using whitespace instead of (most) punctuation to indicate structure, and it supports comments.

Rethinking fsinfo()

Posted Aug 28, 2020 13:13 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

And if we could strip away things like type annotations, the umpteen ways of quoting text blocks (and other incidental possibilities without a complicated escape generator. Sure, you could call it YAML, but the only safe way to actually generate it with arbitrary data is to treat it like JSON because no one wants to write escape detectors for all of YAML's arcane syntax features.

Don't forget that some parsers have baked in the extension proposals(!) in, so you have to pay attention to things like accidentally generating merge keys ("<<").

Rethinking fsinfo()

Posted Aug 28, 2020 12:13 UTC (Fri) by mvdwege (guest, #113583) [Link]

Best solution: discard the dogmatic adherence to 'it must be text'. If the primary consumer of the information is not a sysadmin at the console, use binary data and cut out the redundant parsing step.

Yes, 'everything is an ASCII stream' makes things easily readable for humans, and it is great if you have text tools to write ad-hoc parsers for it. The problem is that you keep writing ad-hoc parsers. A little more pragmatism on this old UNIX dogma would be appreciated.

I'm speaking as a sysadmin/developer who ran into this when I wanted to verify if my local MTA had successfully sent (aka received a 250 reply) an email. The only way to do that was to parse fscking syslog. In 2018. When tools like D-Bus notification already had existed for over a decade.