Just a quick note that the long-festering DM-4141 is finally fixed; if I did it right, command line tasks (including calibration tasks in pipe_drivers) should now return proper unix error codes upon failure.
More completely, the tasks return the number of dataRef that failed (so if nothing fails you get 0, which unix considers as success).
The error exit comes from ParseAndRun so the calling script (usually in bin) will not see the task return; if you want to avoid this you can specify --noExit, but then you’ll have to handle the errors yourself.
I don’t know a specific solution yet, but I have the feeling there are usability issues with the name of this new argument --noExit and the help string:
Do not exit even upon failure (i.e. return a struct to the calling script)
I think it’s that the flag/help string are breaking the encapsulation of the command line program and requiring the user to know the difference between the script itself and the ParseAndRun internals. The user certainly wouldn’t know about the struct.
Can we think of a better way to describe/document this feature?
Jonathan and I discussed this on slack (after I fixed master which I’d broken – my excuse for being terse here). To quote me:
I only added it because almost all the cmdLineTask scripts run the python from a boilerplate script in bin which ignores the return values; because they basically don’t expect the Task to return it seemed OK to call exit within the Task rather than delegating to the highest level of the calling tree (which would have required changes to every driver script). However, calling sys.exit is usually a rude thing to do so I felt that I had to provide a way to bypass it
So --noExitStatus isn’t quite right; it’s preventing parseAndRun from exiting so I still prefer --noExit