Provide a third state to `strict` which omits `set -e` about bashly

[DannyBen]

Lets keep this open. I need to sleep on it, perhaps allow a string value in strict so you can set an empty string or whatever else you want.

[DannyBen]

Well, thanks, but I have several issues with this proposal.

Issue 1: set -e is needed by bashly.

The code generated by bashly itself (i.e. not user code) relies on set -e to be set. In my experience, when you need it to NOT be set, it is a code smell that has multiple solutions other than calling set +e.

In your example, the problem is not with the variable test [[ "${args["--force"]}" ]], but rather with the fact that you just use return instead of return 0.

This minor tweak makes it work without disabling set -e:

#!/usr/bin/env bash
declare -A args
set -e

func() {
  [[ "${args["--force"]}" ]] || return 0
  echo "--force is set, continuing to do something"
}

# args["--force"]='1'
func
echo "end of script"

Also additional tip: Personally, I try to avoid shortcuts that look cool and compact. Be explicit:

func() {
  # instead of this...
  # [[ "${args["--force"]}" ]] || return 0

  # ...do this
  if [[ -z "${args["--force"]}" ]]; then
    return 0
  fi
  
  echo "--force is set, continuing to do something"
}

Issue 2: Confusing options.

Having a setting that can accept true, false, disabled, or none is confusing, as three of these words are synonyms to false. I do not like manual.

Issue 3: This is overridable in user-land.

Finally, if someone for some reason does not care about my first argument, they can always override it as they see fit in the initialize.sh. Of course this will result in set -e followed immediately by set +e, which - for someone who reads the script - might seem awkward, but it should serve as a sign that this should not be done.

It is ok to do this for debugging purposes of course, but I would not recommend leaving the final resulting script with it.

---

Bashly itself tries to stay out of your way, but still nudge you towards good standards and practices.
In my opinion, set -e is a bare minimum safety measure - disabling it globally may cause your generated script to behave unexpectedly.

[halostatue]

I disagree about the benefits of set -e; as I noted, I had silent early termination which was substantially harder to debug than if the script had continued.

The BashFAQ also indicates that set -e provides a tissue instead of a safety blanket: https://mywiki.wooledge.org/BashFAQ/105 because there’s a lot of corner cases. This is one of the reasons why I have explicitly not used set -e on all but the simplest of shell scripts but instead explicitly check for errors on lines where failure or success matters.

If set -e cannot be removed from Bashly safely, then I’ll probably have to make a prefix/suffix for all of my functions to disable/enable it for anything that is in my code, because I find set -e unusable and untrustworthy. (And yes, I use a lot of subshell calls, which is one of the places where set -e fails fairly hard.)

I agree with you about the confusing options; I do think that some other configuration option for this would be better.

[DannyBen]

Even in the link you posted, the very last Conclusion paragraph states two opposite opinions. On says use it, the other don't.

The set -e option in bash is the closest thing to how all other languages operate - when there is an error, exit. Non zero return code in bash is error.

That said - bashly should not fight you if you feel otherwise.
I will execute all specs without set -e first, see if things pass. If they do, then the door may be open to allowing users to set whatever they want.

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 set +e, it would help expedite resolving this.

[DannyBen]

Specs pass with set +e. So I suggest you set this in your initialize.sh, and see if you have any issues.
If you do, please report them.

[halostatue]

OK. Thanks for your thoughts on this.

[DannyBen]

I have changed the strict setting to allow any string. This does not change how the true or false values work.

Can you take a look and see if it covers your use case in a satisfactory manner?

[halostatue]

Looks great. Thanks again for such a useful project.

[DannyBen]

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.

[DannyBen]

Released in 1.0.1