Re: [fossil-users] Command-line output format

2017-03-29 Thread Warren Young
On Mar 29, 2017, at 8:40 AM, Warren Young  wrote:
> 
>   https://unix.stackexchange.com/questions/

Oops, over-edited that URL:

https://unix.stackexchange.com/questions/121718/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Command-line output format

2017-03-29 Thread Warren Young
On Mar 28, 2017, at 1:16 AM, Florian Balmer  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


Re: [fossil-users] Command-line output format

2017-03-28 Thread j. van den hoff
On Tue, 28 Mar 2017 09:16:33 +0200, Florian Balmer  
 wrote:



Citation from:

http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24841.html


... What can we do to help you move away from scripts that depend
on the details of command-line output and toward something that is
more likely to survive an update? ... Would it be better to run
SQL queries directly against the repository database? ... Are new
fixed-output-format commands needed in Fossil to extract
information that is important to scripts?


I'm working with a lot of scripts to process Fossil command-line output.

The JSON interface is not available with some of the precompiled
binaries I'm using, and parsing JSON from shell scripts or Windows
batch files seems not so trivial.

Running SQL queries directly would mean to reinvent the wheel and
perform complex operations in many cases, as i.e. the output of
`fossil whatis [check-in]` involves parsing and integrating all
amendments to a check-in (or thorough knowledge of the internal Fossil
storage format if this information is cached in some table).

Therefore, 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.


+1



--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] Command-line output format

2017-03-28 Thread Florian Balmer
Citation from:

http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24841.html

> ... What can we do to help you move away from scripts that depend
> on the details of command-line output and toward something that is
> more likely to survive an update? ... Would it be better to run
> SQL queries directly against the repository database? ... Are new
> fixed-output-format commands needed in Fossil to extract
> information that is important to scripts?

I'm working with a lot of scripts to process Fossil command-line output.

The JSON interface is not available with some of the precompiled
binaries I'm using, and parsing JSON from shell scripts or Windows
batch files seems not so trivial.

Running SQL queries directly would mean to reinvent the wheel and
perform complex operations in many cases, as i.e. the output of
`fossil whatis [check-in]` involves parsing and integrating all
amendments to a check-in (or thorough knowledge of the internal Fossil
storage format if this information is cached in some table).

Therefore, 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.

--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users