-
-
Notifications
You must be signed in to change notification settings - Fork 85
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
Provide a third state to strict
which omits set -e
#352
Comments
Well, thanks, but I have several issues with this proposal. Issue 1:
|
I disagree about the benefits of The BashFAQ also indicates that If I agree with you about the confusing options; I do think that some other configuration option for this would be better. |
Even in the link you posted, the very last Conclusion paragraph states two opposite opinions. On says use it, the other don't. The That said - bashly should not fight you if you feel otherwise. If you can take a look anywhere in the code (either the bashly source code, or your generated code) and see if there are things that might fail with |
Specs pass with |
OK. Thanks for your thoughts on this. |
Lets keep this open. I need to sleep on it, perhaps allow a string value in |
I have changed the Can you take a look and see if it covers your use case in a satisfactory manner? |
Looks great. Thanks again for such a useful project. |
Excellent. I have built an edge docker, assuming you can use it (or the GitHub version) until next release (instructions). Release will be coming soon. |
Released in 1.0.1 |
Description
I usually write my shell scripts without
set -e
, because exits too quietly. Instead, I have a pair of standard functions (fail-unless
andhalt
) which let me control flow much better and provide better messaging. I findset -e
dangerous precisely because it turns harmless failures like the example below into silent halts.[[ "${args["--force"]} ]] || return
I was debugging a script yesterday that was halting for unexplained reasons that became clear when I saw the generated script included
set -e
. I was able to resolve this withset +e
, but when I use these, I prefer to useset +e -o pipefail
(I might include-u
, but I generally declare every variable that I use).IMO, the states could be:
strict: true
:set -euo pipefail
strict: false
:set -eo pipefail
strict: disabled
:set -o pipefail
strict: manual
: omitted entirely; could benone
, butmanual
declares that I, as the script writer, will take the responsibility for those settings myself.I do think that
set -o pipefail
should be part of the written defaults all the time; there’s almost never a time when you want to hide individual pipe command failures, but I’m less bothered about that.The text was updated successfully, but these errors were encountered: