Hi, When I was implementing Fuel (my take on a Fossil GUI), one of the problems I was facing was not so much catching the success or failure of a command but rather capturing and handling the interactive queries that fossil asks while performing an action (eg. inconsistent EOLs, empty commit messages etc.) occasionally hindered by the fact the query format was not always consistent.
Essentially this means that while Fossil is spawned executing a command, you need to keep parsing the text output in order to detect and handle these cases and, for example, present a dialog box to the user or whatnot. If not fossil will hang in the background waiting for a reply. Another issue the use of stdin/out/err. On Windows since all i/o goes via the console, all text goes through the encoding conversion via codepages. In many cases the fossil output parsing would fail due to incorrect conversion of filenames with international characters, which were not in the current codepage. Another extra problem with spawning a process is that each OS has different limits for command-line arguments. This was a problem for the initial check-in where the user wants to add a lot of new files to a repository but would hit that limit on Windows. Perhaps some kind of method could be added to fossil for driving it non-interactively. Ideally it would bypass stdio/err and allow talking to a fossil process via a socket or something similar, using a protocol (JSON?) that also supports the interactive queries that fossil occasionally requires. Filenames should be expressed in a single consistent encoding (say utf-8). Cheers On 8 June 2013 00:17, tpero...@compumation.com <tpero...@compumation.com> wrote: > I wrote a simple GUI for Fossil using .NET for myself. After reviewing the > source code for the commands I used, I concluded that all errors were written > to stderr. > By redirecting and displaying stdout / stderr I was able to provide feedback > as to the success or failure of a command. > > Also, fossil.exe exits with zero if all is well, otherwise non-zero: > > fossil_exit(0); > or > fossil_exit(1); > > Tony Perovic > Compumation, Inc. > > -----Original Message----- > From: fossil-users-boun...@lists.fossil-scm.org > [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Gilles > Sent: Friday, June 07, 2013 6:00 AM > To: fossil-users@lists.fossil-scm.org > Subject: [fossil-users] Fossil.exe: Catching errors? > > Hello > > I'd like to write a GUI front-end for fossil.exe to avoid having to > open a DOS box and type Fossil commands. > > Does someone know of a way to catch errors, if any, instead of parsing the > output returned by the application to figure it out? > > Thank you. > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users