Можно ли найти подход для выполнения set -e/ERR захвата подоболочки, невосприимчивого к && и || ограничения?

Этот код НЕ является решением. Это модифицированная версия, которую вы можете протестировать, чтобы получить некоторые идеи.

#!/bin/bash

main()
{
   local Arg="$1"
   (
      echo "In main: $Arg"
      $(exit 1)
      echo "Should not get here"
   )

   return 1
}

MyTrap()
{
   echo "In MyTrap"
   exit 1
}

set -o errtrace
set -o functrace
trap MyTrap ERR

main 1
[[ $? -eq 0 ]] || echo "failed"
echo
main 2 || echo "failed"

Он не будет делать то, что вы хотели бы (я предполагаю), потому что не хватает чего-то важного, что слишком сложно объяснить в посте, но есть несколько ключевых моментов.

Если вы хотите единообразно обрабатывать ошибки во всем вашем скрипте, вам придется сделать следующее.

• Установите ловушку на верхнем уровне и НЕ используйте set -e
• Используйте параметры оболочки, которые заставляют подоболочки и функции наследовать ловушки (показано в примере)
• Создайте структуру, в которой вы будете различать «ожидаемые» ошибки (явно обрабатываемые как исключения, а не как коды возврата) и «неожиданные» исключения (ошибки), которые будут перехватываться.
• Никогда не используйте логические операторы напрямую (за исключением тестовых конструкций или других простых операторов, которые вы считаете достаточно безопасными).
• Выполняйте логические тесты после сбора исключений, а не как тесты кодов возврата.

Создать эту структуру очень сложно, но выполнимо (у меня она безупречно работает с десятками очень сложных скриптов). После того, как вы это сделаете, если вы решили слепо протестировать команду (без явной обработки исключений), в случае сбоя у вас есть возможность сбросить ваш скрипт в ловушку (exit) вместо того, чтобы продолжать выполнение с вашим скриптом в нестабильном состоянии.

Это, вероятно, влечет за собой небольшое снижение производительности (по крайней мере, так, как я это сделал, используя специальную функцию try, предшествующую каждому оператору, для которого используется обработка исключений), и, конечно, требует МНОГО дисциплины в кодировании, но в моем случае это заставляет меня более продуктивное создание сложных сценариев с разумной уверенностью, что местоположение любой ошибки (не то, чтобы у меня было что-то из этого...) будет намного проще определить.