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:
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 suspected.
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.