Closed kwesolowski closed 5 years ago
Basically related to #26
Good point. guardonce prints an error but keeps going even if there's a problem when reading, writing or processing a file. That was useful behaviour when I was using it to migrate repositories, because changing one file manually is usually easier than fixing the underlying problem. But, I definitely was not thinking too carefully about error codes for automation.
As a workaround, you can check stderr for output.
I agree that you should not interrupt on first error, but returning -1 in case of manual (recursive for example) call that had problem would do no harm, and it would be good to have clear indication if tool worked or crashed ;)
i.e. i was capturing stdout, so without that indication i got empty file :)
I can use stderr != as a workaround, but would be good to know if you plan to improve exit statuses? Or if not would you accept pull request?
The error status is a bug, and I do intend to fix it. I would accept a PR, too.
When guard2once failed it still returned 0 exit code, causing script to misinterpret its output.