On Mar 28, 2017, at 1:16 AM, Florian Balmer <florian.bal...@gmail.com> wrote: > > parsing JSON from shell scripts or Windows > batch files seems not so trivial.
We have no lack of options for JSON parsing on POSIX type systems: https://unix.stackexchange.com/questions/ The top option, jq, is available for Windows: https://stedolan.github.io/jq/ There are many other ways to skin that cat, including this method under PowerShell: https://blogs.technet.microsoft.com/heyscriptingguy/2015/10/08/playing-with-json-and-powershell/ A format like JSON makes all kinds of sense from a reliable parsing standpoint. Parseable plain text is fine, but prone to breakage. Formats like JSON tend to be more robust. JSON is nice in its own right, and little extra work has to go into making it present by default, but if JSON is deemed unsuitable for some reason, there are other self-documenting data languages we could use instead: XML, YAML, TOML, etc. Let’s just not use EDI, okay? :) > I would like to vote for the command-line output to remain > as stable as possible, make the suggested "fixed-output-format" the > default, and carefully document modifications to the command-line > output format in the Fossil change logs. It’s a nice sentiment, but over here on the Unix side of things, we can list example after example culled from decades of experience warning about relying on file formats and command output formats to remain stable over long periods of time. e.g. getent(1) and getpwent(3) are better than parsing /etc/passwd, and opendir(3)/stat(2) are better than parsing the output of ls(1). Applying those lessons to Fossil, maybe someone interested in this, such as yourself, would like to help out with the libfossil project? http://fossil.wanderinghorse.net/repos/libfossil/ _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
