On 2017-09-08 14:09, Tomasz Kłoczko wrote:
No, the primary reason that nobody is asking to transform procfs to spit out JSON is that it's a pain to parse (in a shell, you need excessive stuff like the above command, in almost any other language you have to write a special parser or use a separate library) when compared to the simple space and newline delimited stuff already in proc (in Python for example, you just need str.split() and str.splitlines(), both of which are part of the core language), and it's insanely more efficient to just spit out the data as-is without all the extra stuff required by JSON (it's not as bad as XML, but it's still mostly pointless). The only thing that adding JSON support would give people is a way to avoid having to use extra tools or kernel documentation to figure out what everything is, which is not seen as a significant benefit since almost nobody interacts directly with anything in /proc other than developers and people poking at sysctls.On 8 September 2017 at 17:39, David Sterba <dsterba@xxxxxxx> wrote: [..]My plan is to introduce a global options to set various this, also the output format, eg. $ btrfs -t bell be om -format=json subvolume list that would dump the list in json obviously, more formats could follow. This requires to switch all printf to a wrapper that would select the format based on global config. Some of the code is there, eg. the global option parser and the config structure. The printf transitions can be done incrementally. All of that is easy IMHO, somebody just needs to do it. I work on that when there are no other more pressing things to do.What in the future json will be abandoned and some new/fancy parseable output will be most desirable? Hmm ?? Seems some people never saw or already forgot some old jokes. http://www.webaugur.com/bazaar/53-what-if-operating-systems-were-airlines.html "Unix Airlines Each passenger brings a piece of the airplane and a box of tools to the airport. They gather on the tarmac*, arguing constantly about what kind of plane they want to build and how to put it together. Eventually, *they build several different aircraft*, but give them all the same name. Some passengers actually *reach their destination*" So how to apply above to generate json output out of simple list? Try below command on your linux: $ awk 'BEGIN {print "{\"data\":["; ORS=""} {if (NR!=1) {print ",\n"}; print "{\"{#DISK}\":\"" $3 "\"}"} END {print "\n]}\n"}' /proc/diskstats ***This is why no one is asking to transform Linux kernel procfs to provide json output** as standard or an option. (try to think few seconds on this)
As long as something is able to produce list with comma or spaces
separated fields to process such list and provide some usable json
output you need only:
$ (echo "foo:foo"; echo "bar:bar") | awk -F: 'BEGIN {print
"{\"data\":["; ORS=""} {if (NR!=1) {print ",\n"}; print
"{\"{#FOO}\":{\""$1"\",\""$2"\"}}"} END {print "\n]}\n"}'
{"data":[
{"{#FOO}":{"foo","foo"}},
{"{#FOO}":{"bar","bar"}}
]}
If you don't like awk you can use jq, sed, perl, python, ruby or
whatever you have/like/want.
And which command is more readable? Something like the above, or: btrfs device stats --format=json /Almost anybody is going to say that the second case (with a simple option) is more readable, and it's also almost always going to be more efficient too since you don't have to fork() an extra time and deal with another pipe. Even using the other tools you mentioned, none of them is going to be as trivially easy for people to understand what's going on as just having an extra option to control the output format.
With the added constraint that your output should be self consistent and sensibly arranged. The current output from various btrfs commands is designed to be human readable, and does not consistently conform to the same formatting. It's also a serious pain to parse without using a language with proper string operations (take a look at the output of `btrfs device stats` for an example, it uses runs of spaces to separate and align fields, which is ridiculous to try and parse in a shell script), and the lack of a standard output format means that anything interacting with it is inherently fragile.However on writing fs tools all what you really *must do* is define *as simple as it is only possible >stable< interface*. Only this and nothing more.
This is a case though where having something that's more easily machine parseable is a significant benefit, because the command-line is the API unless you're willing to fight with ioctls.Really on writing something so simple like fs tools you don't need to think about future possibility to solve problem of famine on Earth (using your code).
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
