Warum funktioniert set -e nicht in Subshells mit Klammern () gefolgt von einer ODER-Liste ||?

Ich habe in letzter Zeit einige Skripte wie diese gefunden:

( set -e ; do-stuff; do-more-stuff; ) || echo failed

Das sieht für mich gut aus, aber es funktioniert nicht! Das set -egilt nicht, wenn Sie das hinzufügen ||. Ohne das funktioniert es gut:

$ ( set -e; false; echo passed; ); echo $?
1

Wenn ich jedoch das hinzufüge ||, set -ewird das ignoriert:

$ ( set -e; false; echo passed; ) || echo failed
passed

Die Verwendung einer echten, separaten Shell funktioniert wie erwartet:

$ sh -c 'set -e; false; echo passed;' || echo failed
failed

Ich habe dies in mehreren verschiedenen Shells versucht (bash, dash, ksh93) und alle verhalten sich gleich, es ist also kein Fehler. Kann das jemand erklären?

Nach diesem Thread , dann ist es das Verhalten POSIX legt fest , für die Verwendung von „ set -e“ in einer Subshell.

(Ich war auch überrascht.)

Erstens das Verhalten:

Die -eEinstellung wird ignoriert, wenn die zusammengesetzte Liste nach while ausgeführt wird, bis oder falls elif ein reserviertes Wort ist, eine Pipeline, die mit! Beginnt. reserviertes Wort oder ein beliebiger Befehl einer AND-OR-Liste außer dem letzten.

Der zweite Beitrag stellt fest,

Zusammenfassend gesagt, sollte set -e in (Subshell-Code) nicht unabhängig vom umgebenden Kontext funktionieren?

Nein. Der POSIX-Beschreibung ist klar, dass der umgebende Kontext Einfluss darauf hat, ob set -e in einer Subshell ignoriert wird.

Es gibt ein wenig mehr im vierten Beitrag, auch von Eric Blake,

Punkt 3 erfordert keine Unterschalen, um die Kontexte zu überschreiben, in denen set -eignoriert wird. Das heißt, wenn Sie sich in einem Kontext befinden, in dem Sie -eignoriert werden, können Sie nichts tun, um -eerneut gehorcht zu werden, nicht einmal eine Unterschale.

$ bash -c 'set -e; if (set -e; false; echo hi); then :; fi; echo $?' 
hi 
0 

Auch wenn wir set -ezweimal aufgerufen haben (sowohl in der übergeordneten als auch in der Subshell), dass die Subshell in einem Kontext vorhanden -eist, in dem sie ignoriert wird (die Bedingung einer if-Anweisung), können wir in der Subshell nichts tun, um sie wieder zu aktivieren -e.

Dieses Verhalten ist auf jeden Fall überraschend. Es ist kontraintuitiv: Man würde erwarten, dass die erneute Aktivierung von set -eeine Wirkung hat und dass der umgebende Kontext keinen Präzedenzfall darstellt; Darüber hinaus macht der Wortlaut des POSIX-Standards dies nicht besonders deutlich. Wenn Sie es in dem Kontext lesen, in dem der Befehl fehlschlägt, gilt die Regel nicht: Es gilt nur im umgebenden Kontext, es gilt jedoch vollständig für ihn.

set -eHat in der Tat keine Auswirkung in Subshells, wenn Sie den ||Operator danach verwenden. zB würde das nicht funktionieren:

#!/bin/sh

# prints:
#
# --> outer
# --> inner
# ./so_1.sh: line 16: some_failed_command: command not found
# <-- inner
# <-- outer

set -e

outer() {
  echo '--> outer'
  (inner) || {
    exit_code=$?
    echo '--> cleanup'
    return $exit_code
  }
  echo '<-- outer'
}

inner() {
  set -e
  echo '--> inner'
  some_failed_command
  echo '<-- inner'
}

outer

Aaron D. Marasco erklärt in seiner Antwort hervorragend, warum es sich so verhält.

Hier ist ein kleiner Trick, mit dem dies behoben werden kann: Führen Sie den inneren Befehl im Hintergrund aus und warten Sie sofort darauf. Der waiteingebaute Code gibt den Exit-Code des inneren Befehls zurück. Jetzt verwenden Sie ||after wait, nicht die innere Funktion, und set -efunktioniert in letzterer ordnungsgemäß:

#!/bin/sh

# prints:
#
# --> outer
# --> inner
# ./so_2.sh: line 27: some_failed_command: command not found
# --> cleanup

set -e

outer() {
  echo '--> outer'
  inner &
  wait $! || {
    exit_code=$?
    echo '--> cleanup'
    return $exit_code
  }
  echo '<-- outer'
}

inner() {
  set -e
  echo '--> inner'
  some_failed_command
  echo '<-- inner'
}

outer

Hier ist die generische Funktion, die auf dieser Idee aufbaut. Es sollte in allen POSIX-kompatiblen Shells funktionieren, wenn Sie localSchlüsselwörter entfernen , dh alle local x=ydurch Folgendes ersetzen x=y:

# [CLEANUP=cleanup_cmd] run cmd [args...]
#
# `cmd` and `args...` A command to run and its arguments.
#
# `cleanup_cmd` A command that is called after cmd has exited,
# and gets passed the same arguments as cmd. Additionally, the
# following environment variables are available to that command:
#
# - `RUN_CMD` contains the `cmd` that was passed to `run`;
# - `RUN_EXIT_CODE` contains the exit code of the command.
#
# If `cleanup_cmd` is set, `run` will return the exit code of that
# command. Otherwise, it will return the exit code of `cmd`.
#
run() {
  local cmd="$1"; shift
  local exit_code=0

  local e_was_set=1; if ! is_shell_attribute_set e; then
    set -e
    e_was_set=0
  fi

  "$cmd" "$@" &

  wait $! || {
    exit_code=$?
  }

  if [ "$e_was_set" = 0 ] && is_shell_attribute_set e; then
    set +e
  fi

  if [ -n "$CLEANUP" ]; then
    RUN_CMD="$cmd" RUN_EXIT_CODE="$exit_code" "$CLEANUP" "$@"
    return $?
  fi

  return $exit_code
}


is_shell_attribute_set() { # attribute, like "x"
  case "$-" in
    *"$1"*) return 0 ;;
    *)    return 1 ;;
  esac
}

Anwendungsbeispiel:

#!/bin/sh
set -e

# Source the file with the definition of `run` (previous code snippet).
# Alternatively, you may paste that code directly here and comment the next line.
. ./utils.sh


main() {
  echo "--> main: $@"
  CLEANUP=cleanup run inner "$@"
  echo "<-- main"
}


inner() {
  echo "--> inner: $@"
  sleep 0.5; if [ "$1" = 'fail' ]; then
    oh_my_god_look_at_this
  fi
  echo "<-- inner"
}


cleanup() {
  echo "--> cleanup: $@"
  echo "    RUN_CMD = '$RUN_CMD'"
  echo "    RUN_EXIT_CODE = $RUN_EXIT_CODE"
  sleep 0.3
  echo '<-- cleanup'
  return $RUN_EXIT_CODE
}

main "$@"

Beispiel ausführen:

$ ./so_3 fail; echo "exit code: $?"

--> main: fail
--> inner: fail
./so_3: line 15: oh_my_god_look_at_this: command not found
--> cleanup: fail
    RUN_CMD = 'inner'
    RUN_EXIT_CODE = 127
<-- cleanup
exit code: 127

$ ./so_3 pass; echo "exit code: $?"

--> main: pass
--> inner: pass
<-- inner
--> cleanup: pass
    RUN_CMD = 'inner'
    RUN_EXIT_CODE = 0
<-- cleanup
<-- main
exit code: 0

Das einzige, was Sie beachten müssen, wenn Sie diese Methode verwenden, ist, dass alle Änderungen an Shell-Variablen, die Sie mit dem übergebenen Befehl vornehmen, runnicht an die aufrufende Funktion weitergegeben werden, da der Befehl in einer Subshell ausgeführt wird.

Ich würde nicht ausschließen, dass es ein Fehler ist, nur weil sich mehrere Shells so verhalten. ;-)

Ich habe mehr Spaß zu bieten:

start cmd:> ( eval 'set -e'; false; echo passed; ) || echo failed
passed

start cmd:> ( eval 'set -e; false'; echo passed; ) || echo failed
failed

start cmd:> ( eval 'set -e; false; echo passed;' ) || echo failed
failed

Darf ich aus Man Bash zitieren (4.2.24):

Die Shell wird nicht beendet, wenn der fehlgeschlagene [...] Befehl Teil eines Befehls ist, der in einem && oder || ausgeführt wird Liste mit Ausnahme des Befehls nach dem letzten && oder || [...]

Vielleicht führt die Auswertung mehrerer Befehle dazu, dass das || ignoriert wird Kontext.

Problemumgehung, wenn Sie die oberste Ebene verwenden set -e

Ich bin auf diese Frage gekommen, weil ich set -eals Fehlererkennungsmethode Folgendes verwendet habe:

/usr/bin/env bash
set -e
do_stuff
( take_best_sub_action_1; take_best_sub_action_2 ) || do_worse_fallback
do_more_stuff

und ohne ||würde das Skript aufhören zu laufen und niemals erreichen do_more_stuff.

Da es keine saubere Lösung zu geben scheint, denke ich, dass ich set +emeine Skripte einfach bearbeiten werde:

/usr/bin/env bash
set -e
do_stuff
set +e
( take_best_sub_action_1; take_best_sub_action_2 )
exit_status=$?
set -e
if [ "$exit_status" -ne 0 ]; then
  do_worse_fallback
fi
do_more_stuff