Should this not return 0 since if it finds no errors in the commit? It returns 1 even if there are no errors.

That's a fair question. Whoever wrote that code presumably felt that dry-run is worthy of non-zero because it doesn't actually save anything:

https://fossil-scm.org/home/file?ci=90ae5bbf9466e297&name=src%2Fcheckin.c&ln=2849-2852

We can certainly entertain a debate about whether that case should exit with 0. Changing that seems(?) unlikely(??) to have any script-breaking fallout for users.

(FWIW, i'm ambivalent about the result code there.)

If fossil is to be run from a script rather than directly by a human ready to scan blurted output for ERRORish text, the process exit status (aka "return") should be faithful to the --dry-run promise, which I take to be: "Run just as if this option is absent, except effect no changes and say what would be done instead."

For all a Fossil dev knows, --dry-run output is being collected for some purpose. It would be good to not have to analyze that (via code) to avoid the GIGO problem.

A further point: The well established convention is that a non-zero exit status means "Could not do what was asked." I see no reason for a successful --dry-run execution to say otherwise. (Maybe whoever wrote that thought exit status is merely an indication that stuff was done, forgetting that sometimes doing nothing is correct.)

We can certainly entertain a debate about whether that case should exit with 0. Changing that seems(?) unlikely(??) to have any script-breaking fallout for users.

That might be an interesting debate, from the "--dry-run is an error" side.

Without coming down too hard on what "seems" arise in others' minds, I can say that I much appreciate the predictability of *Nix tools that adhere to conventions that I can generally remember without resort to "man ...". The thought that I should instead anticipate how tool programmers foresee my use of their tools in scripts when electing to follow well established convention makes me apprehensive. Please do not weaken the convention by making a perfectly usable command-line tool harder to predict.

Yeah, I traced through the fossil code last night and figured out where to change the return code and then recompiled it. My scripts now work the way I would expect them to but I would prefer not to have to do that every time I install a new version of fossil.

Basically I am using that command to check if the repository is up to date (i.e. no else has checked in anything) and does not need syncing. I'm new to fossil so if there is a better way to do that I am open to suggestions.

Phil

Please do not weaken the convention by making a perfectly usable command-line tool harder to predict.

That all sounds fair to me. i'm only assuming about the initial intent behind the rc=1 for that case - that code is age-old and i didn't write it.

If there are no objections from the public at large, and Richard in particular, i'll change it.

If there are no objections from the public at large, and Richard in particular, i'll change it.

Nevermind: Richard already made this change.

Awesome! Thanks!

Phil