Add machine-readable status indication for sync outcomes

[mikeperalta1]

Hey just a friendly wishlist suggestion. It would be great if we could pass an argument to unison that changes which exit codes it returns. Currently the exit code 0 doesn't seem to specify whether or not any changes were made. Perhaps with some option like "-extended-exit-codes", we could have something like the following:

• 0: successful synchronization; everything is up-to-date now, and no changes were made
• 1: successful synchronization; everything is up-to-date now, and one or more changes were made
• 2: some files were skipped, but all file transfers were successful.
• 3: non-fatal failures occurred during file transfer.
• 4: a fatal error occurred, or the execution was interrupted.

I'm about to solve this problem in one of my own scripts by capturing stdout and looking for the message "Nothing to do: replicas have not changed since last sync", but I feel this is a bit hacky compared to an official exit code.

(or any other "official" method for detecting whether changes were made, would be fine by me)

[bcpierce00]

This sounds useful and low-impact. If someone wants to implement it, I will gladly consider a PR.

But, indeed, the way you’re planning to work around it seems to have plenty of precedent. :-)

On Jan 12, 2020, at 7:02 PM, Mike Peralta [email protected] wrote:

Hey just a friendly wishlist suggestion. It would be great if we could pass an argument to unison that changes which exit codes it returns. Currently the exit code 0 doesn't seem to specify whether or not any changes were made. Perhaps with some option like "-extended-exit-codes", we could have something like the following:

0: successful synchronization; everything is up-to-date now, and no changes were made 1: successful synchronization; everything is up-to-date now, and one or more changes were made 2: some files were skipped, but all file transfers were successful. 3: non-fatal failures occurred during file transfer. 4: a fatal error occurred, or the execution was interrupted. I'm about to solve this problem in one of my own scripts by capturing stdout and looking for the message "Nothing to do: replicas have not changed since last sync", but I feel this is a bit hacky compared to an official exit code.

(or any other "official" method for detecting whether changes were made, would be fine by me)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bcpierce00/unison/issues/310?email_source=notifications&email_token=ABVQQC5OZ44OGK7EFE5CZU3Q5OVP3A5CNFSM4KF2V56KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IFTW6SA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVQQC74ZIPCSAVS4HNR3I3Q5OVP3ANCNFSM4KF2V56A.

[gdt]

UNIX has a long tradition of 0 for ok, non-zero for not ok, and I don't really want to depart from that. I'd be fine with 1 for didn't connect to remote, or other serious error. But "didn't need to sync'" and "some things synced successfully" are both "ok".

That said I am sympathetic to wanting machine-readable status, and I think it makes sense to make reading that somehow actually defined and not so hacky.

[mikeperalta1]

UNIX has a long tradition of 0 for ok, non-zero for not ok, and I don't really want to depart from that. I'd be fine with 1 for didn't connect to remote, or other serious error. But "didn't need to sync'" and "some things synced successfully" are both "ok".

That said I am sympathetic to wanting machine-readable status, and I think it makes sense to make reading that somehow actually defined and not so hacky.

That's a good idea, too. An extra switch that changes output to something more parseable, like JSON, would be great. I'd even be happy with single-line tokens, like:

UNISON_SYNC_RESULT_CONNECTSUCCESS
UNISON_SYNC_RESULT_NOTHINGTOSYNC

or whatever