HN Explorer

26 comments

[ 1.7 ms ] story [ 73.5 ms ] thread
MichaelMoser123
Is there a tool that returns linux system information in json format, that works for most kernel versions and / is actively supported? i think it would be easier to pipe through jq in order to get a desired value, rather then pipe through grep/awk/sed.
bkq
There's jc [1], that can return the JSON output of standard Linux CLI tools.

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

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

LANG=en jc df

fizixer
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.

Xophmeister 

    { "[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.
swiley
If brevity is what you want then what’s wrong with the default field record ls output? It’s even a regular language!
msla
> 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.

tjoff
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.

de_watcher
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.
jhoechtl
Output of systemd can be configured to return JSON:

-o json OR -o json-pretty

arminiusreturns
I was going to say this has come in very handy when shipping from systemd to syslog type parsers.
robmccoll
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.
tomrod
I've needed this for a long time!

One word: anyone know why it Firefox mobile can't scale the page text up? No issue on Brave/Chrome mobile.

JdeBP
Some errors, just from the first few sections alone.

From section 1:

* "man hier" is out of date, alas. https://unix.stackexchange.com/a/567405/5132

* If one is going to have a Linux/FreeBSD/Solaris split, one needs to apply it to section 1. "lsbrelease" is a Linux-based operating system only command.

* Debian now includes /etc/os-release . Interestingly, so too does DragonFlyBSD (but not FreeBSD).

* "last reboot" has been supposedly superseded in systemd operating systems, by "journalctl -b".

* "atacontrol" was superseded by "camcontrol" in FreeBSD back in 2012. https://www.freebsd.org/releases/9.0R/relnotes-detailed.html...

* Not even everyone has /var/log/messages any more, or /var/log/warn . Even Debian has, just last month, made the systemd journal its primary on-disc storage.

* Use "vipw" to avoid having to remember to recompile master.passwd . It respects $EDITOR .

* Most Linux operating systems do not use run levels at all now. http://jdebp.uk./FGA/run-levels-are-history.html

In section 2:

* The ps flags are 30 years out of date for the BSDs. BSD switched ps to use getopt() at the start of the 1990s, and they've officially started with a minus sign all of that time since.

* The better trace program on FreeBSD, and the only one on OpenBSD, is the original BSD ktrace/kdump .

In section 3:

* FreeBSD partitioning is done with "gpart".

I stopped there. There are probably some howlers under installation and shells, given how outdated some of the other stuff was. Debian and Ubuntu changed /bin/sh to the Debian Almquist shell a decade and a bit ago. FreeBSD replaced pkg with pkg-ng in version 9. These are two very common errors that I see.

JadeNB
A lot of these seem to be issues with out-of-date information, which is not unreasonable for a 12-year-old document.
JdeBP
Dated 2016, revision 14.5, if you look.
[dead] savanpatel
Linux is not UNIX os. Kindly update the title.