set -e certainly hasmany issues.

Part of what it does is to forego exiting when a failing command is used as a condition, such as withif,while and&&. It can certainly be surprising, but it's also one of the primary purposes of the mode, so always warning on all of them could get noisy. There are also some corner cases:

# Probably not expected to exitif [ -e .bashrc ] && [ -e .kshrc ]; then ...; else ...; ficd foo && ./configure || true[[ $verbose ]] && set -x# Does exit on failurescript_dir="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

Is the expectation that the user will rewrite AND-lists into; lists orif statements depending on whether they do or don't want the script to exit when the condition fails?

Thanks for the response! Agreed that-e has issues - my hope is to leverage shellcheck to help users better understand and navigate unexpected behaviour.

Is the expectation that the user will rewrite AND-lists into ; lists or if statements depending on whether they do or don't want the script to exit when the condition fails?

I could think of a couple remediations given this warning:

1. Rewrite the&& list intoif if they do not want the script to exit upon failure of the condition check (this is way more intuitive to me - you would expectif foo to not error iffoo is false). IMO; lists shouldalso be treated similarly (why not separate onto multiple lines) because they're also subject to this footgun.
2. Add some kind of#shellcheck-ignore above the line to say "yes I'm sure I don't want the script to exit if anything in the pipeline is false"

If we wanted to make this more user friendly, we couldnot warn if the line ends with|| true or other common cases where it's clear the user knows what they're doing.

I'm not particularly tied to any specific implementation - just feel that there is an opportunity here to help users avoid a footgun. However we go about that is 👍

; lists are fortunately not subject to this, but yes, I think this makes sense.

If the&& is:

• not in a context where exit would already be ignored, such as a condition inif/while or left of||
• not the a context where failurewould be immediately followed by exit, such as in the last and/or-list in the script, subshell, command expansion, or process substitution.

then suggest rewriting it viaif or;/linefeed

Obviously this increases the complexity a bit and is not fair to ask of this small PR, but let me know if you'd still like to give it a whack. All the information can be deduced from walking the list of parent elements (getPath (parentMap params) x), and the first point is already done via the functionisCondition which could also be adapted into aisFinalCommandInShell or similar.

I'm on vacation, might as well mess around with haskell. I'll take a stab at it over the next week and see what happens.

This check would be quite useful, the more I thought about it the more confused I got, so I tested out the whole truth table of common logical operators:

evaluate_boolean() {local expression="$1"local output    output=$(bash -c"set -e;$expression; echo end")local rceval"$expression"    rc=$?if [["$output"=="end" ]];thenecho"$expression returns${rc} and continues"elseecho"$expression returns${rc} and exits"fi}whileread -r expression;do    evaluate_boolean"$expression"done<<EOFfalse && truefalse || truetrue && falsetrue || falsetrue && truetrue || truefalse && falsefalse || false! true! falsetruefalseEOF

false && true returns 1 and continuesfalse || true returns 0 and continuestrue && false returns 1 and exitstrue || false returns 0 and continuestrue && true returns 0 and continuestrue || true returns 0 and continuesfalse && false returns 1 and continuesfalse || false returns 1 and exits! true returns 1 and continues! false returns 0 and continuestrue returns 0 and continuesfalse returns 1 and exits

With|| exit codes and whetherset -e will cause the shell to exit or not matches, but&& and even! can have unintuitive behaviours.

My highlight isfalse && false returns 1 and continues.

These results are very confusing so I'd love my script to have some bug I've missed, but I've tested the most egregious results in a plain shell and could reproduce them.

The documentation forset -ehttps://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set explains it, but it's still very unintuitive.