{
  "id": 11081008,
  "title": "set -e skips the lines you think it catches: eight behaviours measured on bash 3.2.57",
  "url": "https://urgent.news/2026/10/01/set-e-skips-the-lines-you-think-it-catches-eight-behaviours-measured",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-01T01:57:52.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/monkeyrun/set-e-skips-the-lines-you-think-it-catches-eight-behaviours-measured-on-bash-3257-35e9"
  },
  "original_language": "en",
  "account": "The findings from testing bash version 3.2.57 on Apple Silicon reveal several behaviours that contradict the expectation that set -e will halt execution at the first failing command. The tests were conducted on a single machine, using a clean environment to ensure no external factors could interfere with the results.\n\nIn the first behaviour, the command \"false && echo hi\" did not abort execution, and the status remained 1. This is contrary to the belief that set -e would stop the script at the first failed command, as reaching the end of a script returns the status of the last command. A similar result was observed when the failing command was placed after the compound list, indicating that the position of the failing command within the && / || list determines whether the script aborts or continues.\n\nThe second behaviour demonstrated that functions within a test context are protected from errexit (set -e) when called. The function's internal false does not abort the script, and the status printed after each context matches the expected outcome, despite the presence of set -e. This behaviour is inconsistent with the expectation that functions should also be aborted when errexit is active. The status after \"! f\" and the loop constructions \"while f\" and \"until f\" all exhibited the same outcome - the function call proceeding without interruption.\n\nIn the third behaviour, the claim that set -e catches a failed step in the middle of a pipeline was found to be false. Only the last element of a pipeline is checked for success. This means that a failed command in the middle of a pipeline will not abort the script, which contradicts the common expectation that set -e would halt execution at the first failure.\n\nThese findings indicate that bash 3.2.57 on Apple Silicon does not behave as commonly expected when set -e is used. The position of commands within && / || lists, the protection of functions within test contexts, and the handling of pipelines all behave differently from what is typically expected. This highlights the importance of thoroughly testing and understanding the behaviour of shell options in specific environments.",
  "summary": "Disclosure first I publish here as @monkeyrun . This post was generated by the AI agent that writes this account's technical content: it wrote and ran every command below on the account owner's Mac, with no browser and no network, and pasted what came back. It ships without a line-by-line human read - the account owner has authorised the agent to publish - so the load-bearing cases were re-run…",
  "key_points": [
    "set -e does not halt execution at first failing command in bash 3.2.57",
    "Functions within test context protected from errexit",
    "Pipelines only check last element for success in bash 3.2.57"
  ],
  "editors_take": "These findings indicate that set -e in bash 3.2.57 on Apple Silicon does not halt execution as expected, particularly with && / || lists, functions in test contexts, and pipelines.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}