On 11/16/15 7:36 AM, Don Lewis wrote:
On 15 Nov, Allan Jude wrote:
On 2015-11-15 13:06, Garrett Cooper wrote:
On Nov 15, 2015, at 09:51, Andrey Chernov <a...@freebsd.org> wrote:
On 15.11.2015 20:37, Adrian Chadd wrote:
On 15 November 2015 at 09:10, Dan Partelly <dan_parte...@rdsor.ro> wrote:
Meaning, is that simple to push things in head , if somone does the work, even
with with no proper review of the problem at hand , and the proposed solutions ?
Nope and yup. The juniper folk had a solution to a problem multiple
people had requested work on, and their proposal was by far the
furthest along code and use wise.
It's all fine and good making technical decisions based on drawings
and handwaving and philosophizing, but at some point someone has to do
the code. Juniper's libxo was the furthest along in implementation and
production.
It seems it is the only and final argument for libXO existence. I
remember 2 or 3 discussions against libXO spontaneously happens in the
FreeBSD lists, all ended with that, approximately: "we already have the
code and you have just speculations". Alternative and more architecture
clean ideas, like making standalone template-oriented parser probably
based on liXO, are never seriously considered, because nobody will code
it, not for other reasons.
We lack a [dtd/json] spec for tools, so programming for xo'ification doesn't
seems like the best idea in the world to me from a end-user sysadmin/developer
perspective.
I could just as easily use standard tools like awk, grep, sed, and more
advanced languages like perl or Python to parse output, and assuming output
doesn't get a major rewrite, I'd just go with that method that's worked pretty
well for me over the last 10 years of my career..
Cheers,
-NGie
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
The big difference is, a json parser isn't going to blow up if a new
field gets added in the middle, and your awk/grep/sed script probably will.
Or more likely, if some value gets large causing adjacent columns run
together. Or even if you the utility is used to display something where
some of the data contains whitespace.
How is an awk script going to cope with this:
the suggestion I made, which was refered to earlier, was that we add
one very smart tool to our quiver.
one that can take a template, (a grammar decription) and parse these
things in an meaningful manner
There are already tools that do this for HANDWRITING. If we can't do
it for regular computer text I'd be
very surprised. Given a correct front end.. you should be able to
take sample outputs of a program and
generate the template.
Given a few months with no job, lots of money and time, I think it
would be a grand project.
Unfortunately I do not have these conditions so I will limit
complaints to the fact that
"I am not sure this is the way to do this" but I will not stop the
libXO-ification of the utilities.
(not that I could, but I mean that my objections do not raise to the
level of "moral outrage" :-) .
# grep spacey /etc/passwd
spacey user:*:6666:6666:Update Builder:/tmp/spacey:/bin/csh
# su 'spacey user'
% cd ~
% touch 'a file'
% ls -l
total 1
-rw-r--r-- 1 spacey user 6666 0 Nov 15 15:24 a file
vs a json parser:
% ls --libxo json -l
{"__version": "1", "file-information": {"directory": [{"total-blocks":1, "entry": [{"name":"a
file","mode":"-rw-r--r--","mode_octal":644,"links":1,"user":"spacey user","group":"6666","type":"regular","size":0,"modify-time":1447629885}]}]}
}
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
