inverting logic should result in a failing chunk

[lavocatt]

```bash {"stage":"test", "runtime": "bash"}
echo ok || ! echo "will not show up"
oikjoij || ! echo "must show up"
```

I have tested the above, but it doesn't behave the way it should

## stage test with 1 chunks

 SUCCESS  ./d97cb978-4c6b-487b-8760-0a7bb7a77e70.sh in /tmp/2277863598                                                                                                                                             
 INFO  ok
       must show up
 WARNING  + echo ok
          + oikjoij
          ./d97cb978-4c6b-487b-8760-0a7bb7a77e70.sh: line 5: oikjoij: command not found
          + echo 'must show up'
          + echo '### ENV ###'
          + printenv

This is most probably a bug to address.

[lavocatt]

This turns out to probably be a non issue, if we assume that a bash chunk has to behave as a script with -e set.

Using bash, the following script will succeed and "will be outputed" is going to show on the stdout:

set -e
echo toto
nonexistingcommand || ! echo bad stuff
echo will be outputed

Whereas, using bash, the following script will fail at the return false, failing early, and not showing the "will be outputed" message:

set -e
echo toto
nonexistingcommand \
  || { \
  echo bas stuff;
  false;
  }
echo will be outputed

[lavocatt]

however it would be an issue if we assume that the chunk has to behave like an interactive session.

[lavocatt]

Markdown-runner uses set -e to match tutorial step-by-step expectations, but this creates a disconnect between script behavior and interactive shell behavior:

Interactive Shell (what humans experience):

$ oikjoij || ! echo "must show up"
bash: oikjoij: command not found
must show up
$ echo $?
1  # Command failed as expected

Script with set -e (what markdown-runner does):

#!/bin/bash
set -e
oikjoij || ! echo "must show up"
echo "This continues executing"  # ✅ Script continues, exits 0

The Disconnect:

• Humans typing commands see failures when they expect them
• Scripts with set -e have special exemption rules for compound commands (||, &&) that mask failures
• Tutorial authors write commands based on interactive experience, but CI runs them as scripts

The set -e Exemption Rules

From the Bash manual: "This option is also smart enough to not react on failing commands that are part of conditional statements. Moreover, you can append a command with || true for those rare cases where you don’t want a failing command to trigger an immediate exit."

This means:

# Interactive shell: FAILS (exit 1)
oikjoij || ! echo "error"

# Script with set -e: SUCCEEDS (exit 0) 
# Because oikjoij is "part of a || list"

The Human Expectation Gap

Tutorial authors think: "I'll write this like I would in my terminal"

docker --version || echo "Please install Docker first"

What they experience interactively: Command fails appropriately when Docker is missing

What happens in CI: Script succeeds even when Docker is missing, because set -e doesn't apply to the || construct

Good vs Bad Compound Command Patterns

❌ Problematic Pattern (works interactively, fails in CI):

oikjoij || ! echo "must show up"

Problem: Interactive shell fails (exit 1), but set -e script succeeds (exit 0)

✅ Good Pattern (consistent behavior):

minikube kubectl -- wait --for=condition=Available --timeout=2m || {
    echo "Wait command failed. Dumping deployment YAML:"
    minikube kubectl -- get deployment cert-manager-webhook -o yaml
    false  # Explicitly fail - works same in both contexts
}

✅ Alternative Clear Pattern:

if ! oikjoij; then
    echo "oikjoij failed"
    exit 1  # Explicit failure - consistent everywhere
fi

We should enhance the documentation about the set -e vs interactive shell behavioral differences.