On Aug 4, 2018, at 12:13 PM, Gilles <codecompl...@free.fr> wrote:
> But then, "fossil changes" returns nothing either, and it's coherent with the 
> Unix philosophy.

Precisely.  You’re applying Windows mores to a tool that comes out of the Unix 
tradition.  As long as you do that, you’ll have expectation mismatches.

It is not correct to say that Fossil had no output in this case.  Its output 
was the exit status code, which was zero, meaning there was no failure.  Since 
there is also no standard output, that means there are no differences.  You can 
check for this combination in a POSIX shell:

    diffs=$(fossil diff)
    if [ $? = 0 ]
        echo No difference found.
    elif [ -n "$diffs" ]
        echo Difference found.
        echo Program exit failure, code $?.

If you know the history of mathematics, you know what kind of contortions they 
had to go through before they invented the concept of zero.  This is analogous.

If we relied instead on text output to signal “No changes,” it would break if 
Fossil was ever localized:

    if fossil diff | grep -q 'No changes'
        … do something for the change case …
        … do something else for the no-change case …

You’d erroneously end up in the no-change case because the output would be 
“Aucun changement” on an OS configured for a French locale, if Fossil ever gets 
localized for French.

If you doubt the usefulness of such a script, consider a “make release” script, 
which first checks whether there are any changes to unexpected files before 
proceeding.  In one of my projects, the only expected changes upon creating a 
release are a new section in the ChangeLog.md file and a single-line change to 
the VERSION variable within the Makefile; anything else means you’ve probably 
forgotten to check something in separately first.  The above shell script logic 
allows us to test for things like this and stop the process if pilot error is 

If I’ve yet to convince you that this design philosophy is sensible, consider 
that it’s one of several reasons why Unix type systems are far more easily 
scripted than Windows systems, which in turn is one of the largest reasons 
they’ve taken over the cloud space.  You can’t deploy 1000 Windows instances at 
peak load every day and tear them back down as the load decreases when you 
cannot easily and reliably script the process.

I speak from experience.  One of my current Windows software projects drives a 
program that is externally scriptable only by programming to its .NET API.  If 
this program were available on Linux and followed its conventions, I’d expect 
to be able to replace the .NET code and its attendant MSI deployment mess with 
a far simpler shell script.  I’ve probably spent more time getting the MSI 
creator working than I’d have spent writing that shell script.

Incidentally, I asked you for “fossil stat” output in part because I 
anticipated this possibility: it didn’t give you an “EDITED” line for these 
files you’ve been checking for changes.  You will come to notice absences like 
that.  It will be a clue that you either have no changes or that you forgot to 
add a new file to the repository, so Fossil is still ignoring it.
fossil-users mailing list

Reply via email to