4 ms·
There's jc [1], that can return the JSON output of standard Linux CLI tools. [1] - https://github.com/kellyjonbrazil/jc https://github.com/kellyjonbrazil/jc
by bkq 7y ago
There's jc [1], that can return the JSON output of standard Linux CLI tools.
[1] - https://github.com/kellyjonbrazil/jc https://github.com/kellyjonbrazil/jc
- dejj 7y agoThis is neat. Set your locale to English for parsers to work: LANG=en jc df
- fizixer 7y agoOff-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.
- msla 7y ago> 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.
- dejj 7y agoFor a related discussion, see "Evolution of a Haskell Programmer": https://willamette.edu/~fruehr/haskell/evolution.html https://willamette.edu/~fruehr/haskell/evolution.html
- Xophmeister 7y ago{ "[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 7y agoIf brevity is what you want then what’s wrong with the default field record ls output? It’s even a regular language!
- tjoff 7y agoThe 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.