On 2017-09-08 14:09, Tomasz Kłoczko wrote:
On 8 September 2017 at 17:39, David Sterba <dste...@suse.cz> 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)
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.
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.
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.
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.
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).
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
