There's jc [1], that can return the JSON output of standard Linux CLI tools.

[1] - https://github.com/kellyjonbrazil/jc

The answer to 'who would parse the result of ls' is answered in the first example of the readme.

I feel one might be tricked into believing this is a more sensible or stable than awk/sed.

Off-topic: Whenever I start thinking about json (or xml) I get lost in the turtle tower of metadata.

Like 'jc ls' gives json output with following entry format: { "filename": "[actual-filename-string]" }

Then I start asking: why not simply { "[actual-filename-string]" } ?

But then why stop at keyword value pairs? Why not:

{ "keyword": "filename", "value": "[actual-filename-string]" }

But then why not:

{ { "metakeyword": "keyword", "metavalue": "filename" }, { "metakeyword": "value", "metavalue": "[actual-filename-string]" } }

And so on.

Surely I can't be the only one. Would love to have this discussed, where to draw the line (and why), what's the utility, and so on.

> Like 'jc ls' gives json output with following entry format: { "filename": "[actual-filename-string]" }

> Then I start asking: why not simply { "[actual-filename-string]" } ?

Because the first at least has a stab at being self-documenting, and maybe even forwards- and backwards-compatible: The file is saying what the values are (unless you're kinda dumb when choosing keys) and, since programs can ask for values by name, older programs won't have to deal with keys added by newer versions and newer programs can deal with missing values more gracefully than abandoning a whole parse because the record has six values instead of ten.

> But then why not:

> { { "metakeyword": "keyword", "metavalue": "filename" }, { "metakeyword": "value", "metavalue": "[actual-filename-string]" } }

Same information, now more verbose. Is there ever going to be a key other than "metakeyword" in that slot? If not, drop it.

    { "[actual-filename-string]" }

...isn't valid JSON. As for going up the metatower, my personal take on this would be to strive for brevity. That is, what's the least structure we can get away with to unambiguously serialise what is needed? In most(?) cases, this is probably best:

    { "filename": "whatever", "foo": "bar", "etc": "etc" }

However, maybe there are instances where:

    [
      { "attribute": "filename", "value": "whatever" },
      { "attribute": "foo", "value": "bar" },
      { "attribute": "etc", "value": "etc" }
    ]

...is more appropriate. If, for example, you need to encode a flexible schema, rather than a fixed one.

If brevity is what you want then what’s wrong with the default field record ls output? It’s even a regular language!

For a related discussion, see "Evolution of a Haskell Programmer": https://willamette.edu/~fruehr/haskell/evolution.html

This is neat. Set your locale to English for parsers to work:

LANG=en jc df

Oh, that "easier" is very much a matter of preference. For me jq/yq is long syntax, slow execution, needs installation, format of the numbers is questionable. Netplan with its yaml config made into the mainstream, so there is hope that problems will be addressed because of friction it and similar subsystems create.

I realize this doesn't give you JSON, but if the goal is to retrieve information with little-to-no parsing, /etc/os-release defines everything in environment variable format. You can just source it and then use the environment variables directly for distro info.

Output of systemd can be configured to return JSON:

-o json OR -o json-pretty

I was going to say this has come in very handy when shipping from systemd to syslog type parsers.

There's facter (used by and developed for Puppet): https://github.com/puppetlabs/facter

Pass --json for JSON output.