Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
The 0 exit code is a little misleading #540
As it is implemented right now, the 0 exit code is a little misleading: as it happens for every other program I know, a 0 exit code should be returned if absolutely no problem occurred, not even a warning, so that, for example, you can use it in a script to send an email saying "backup successful".
I just executed a backup, a file was not backed up, but I still got a 0 exit code!
Some questions I asked myself:
I think exit codes were invented to avoid this kind of problems.
My proposal: why not to add another exit code in case of any warning or problem during the backup?
Here is my backup output that gave me 0 exit code, look at the last line:
What about adding an argument that lets us change the exit code behavior? If the argument isn't specified, the behavior stays the same, but if we specify an argument like
@gilbertchen is afraid of breaking existing backup scripts. I try to analyze the possible cases to show there would be no breaking.
Every kind of backup script I can think of, can do 4 things with the exit code:
If we add an additional exit code for "not included files" the script behaviour in the previous 4 cases would change as follows:
In case there aren't "not included files" (most common situation):
In case there are "not included files":
Now, in my opinion the higher priority should be not to give false sense of security (case # 2).
Good analysis. I'm definitely in agreement with @drsound here. I don't see any way in which adding a status code for incomplete/failed backups would break existing scripts in a bad way.
If someone's ignoring the exit code, there really is no change. If someone's using
Further, if someone's checking exit codes, they pretty much are guaranteed to be knowledgeable enough to have the script send an alert on non-zero exit codes or otherwise just abort on failure and call into something like dead man's snitch on success, and the script aborting on the non-zero would cause DMS or similar to alert since the final check-in would short circuit out.
So I'm running running duplicacy web and it shows all my backups as succeeding (they were green). But when I clicked on the backup status I saw a bunch of permission error warnings, so half my data wasn't actually backed up. This is a very scary situation to be in. The exit code needs to indicate these failures.
pylint uses a bit mask as the exit code. That might be useful so the log files don't need to be parsed to determine what type of errors happened.