-
-
Notifications
You must be signed in to change notification settings - Fork 732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
return codes #61
Comments
I like how Syncthing does it: For example, 5 signals that the process is restarting due to an upgrade. This information can be useful to the process supervision system. So, perhaps think about what we would want to do about different kinds of exits, give each one a code, and document it. Another option is to group exits are different but that we think should be handled in the same way, and give them all the same exit codes. But I think this approach tries to read the user's mind too much and should be avoided. The great thing about good exit codes is that you don't really have to parse them at all :) On June 20, 2015 5:24:34 PM EDT, TW notifications@github.com wrote:
|
@lfam thanks for pointing at syncthing docs, I added the 128+N rc for signals. |
If someone wants to help: research how other backup commandline tools handle return codes and document it here (link it from here). |
This is how fbackup does:
|
rsnapshot: http://linux.die.net/man/1/rsnapshot
|
GNU tar: http://www.gnu.org/software/tar/manual/html_section/tar_19.html
That last paragraph is interesting... |
Duplicity: http://duplicity.nongnu.org/epydoc/duplicity.log.ErrorCode-class.html
|
rdiff-backup: http://www.nongnu.org/rdiff-backup/rdiff-backup.1.html
rdiff-backup also has an error policy, which I think is a good approach for backup software: http://www.nongnu.org/rdiff-backup/error_policy.html |
bsdtar
OpenBSD: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tar.1?query=tar&sec=1
|
It seems that even a return value of 1 is not defined consistently, since for GNU tar it does not mean "otherwise undefined fatal error". I like Duplicity's approach. It provides a rich interface for shell scripting that does NOT involve parsing strings. Sure, it could get messy (okay, it probably already has... what is 'user_error'?), but it's nice to treat 'backend_no_space' differently from 'connection_failed'. |
if we are going to go Duplicity's way, it seems the proper way would be to have a library of Python exceptions with each its own unique integer identifier, and fire those as relevant. but it seems a little cracked up: i think returning 1 on errors, 0 on success would be sufficient, provided the error message is meaningful. although 128+N is seems useful for splitting between external and internal error conditions... |
Maybe the smallest change that would make most people happy would be something like: |
would be fine with me. basically the same distinction as in #57 then... |
working on this. |
how shall we deal with return codes of borg?
currently it is:
0 == no error, normal termination
1 == some error
this could be way more informative. :)
0 == no error, normal termination
1 == some error that hasn't been assigned a better rc yet
2... == other separately identifiable conditions
128+N == killed by signal N
what I am asking myself:
are there standard return codes for some stuff or does everybody invent them individually?
update: i found sysexits.h - maybe better than nothing.
what rc do we use if some files could not get processed (not found, permissions problems, ...), but the rest was ok?
💰 there is a bounty for this
The text was updated successfully, but these errors were encountered: