bash: comment propager les erreurs de substitution de processus?

Je veux que mes scripts shell échouent chaque fois qu'une commande exécutée avec eux échoue.

En général, je le fais avec:

set -e
set -o pipefail

(généralement j'ajoute set -uaussi)

Le fait est que rien de ce qui précède ne fonctionne avec la substitution de processus. Ce code affiche "ok" et quitte avec le code retour = 0, alors que j'aimerais qu'il échoue:

#!/bin/bash -e
set -o pipefail
cat <(false) <(echo ok)

Y a-t-il quelque chose d'équivalent à "pipefail" sauf pour la substitution de processus? Est-il possible de transmettre à une commande la sortie des commandes telles qu'elles étaient des fichiers, mais déclencher une erreur chaque fois que l'un de ces programmes échoue?

La solution d'un pauvre serait de détecter si ces commandes écrivent sur stderr (mais certaines commandes écrivent sur stderr dans des scénarios réussis).

Une autre solution plus conforme à Posix consisterait à utiliser des canaux nommés, mais je dois lancer ces commandes qui utilisent la substitution de processus comme des oneliners construits à la volée à partir du code compilé, et la création de canaux nommés compliquerait les choses (commandes supplémentaires, erreur de piégeage pour les supprimer, etc.)

Vous ne pouvez contourner ce problème qu'avec cela, par exemple:

cat <(false || kill $$) <(echo ok)
other_command

Le sous-shell du script est SIGTERMd avant que la deuxième commande puisse être exécutée ( other_command). La echo okcommande est exécutée "parfois": le problème est que les substitutions de processus sont asynchrones. Il n'y a aucune garantie que la kill $$commande est exécutée avant ou après la echo okcommande. C'est une question de planification des systèmes d'exploitation.

Considérez un script bash comme celui-ci:

#!/bin/bash
set -e
set -o pipefail
cat <(echo pre) <(false || kill $$) <(echo post)
echo "you will never see this"

La sortie de ce script peut être:

$ ./script
Terminated
$ echo $?
143           # it's 128 + 15 (signal number of SIGTERM)

Ou:

$ ./script
Terminated
$ pre
post

$ echo $?
143

Vous pouvez l'essayer et après quelques essais, vous verrez les deux ordres différents dans la sortie. Dans le premier, le script a été interrompu avant que les deux autres echocommandes puissent écrire dans le descripteur de fichier. Dans le second, la falseou la killcommande était probablement programmée après les echocommandes.

Ou pour être plus précis: l'appel système signal()de l' killutillité qui envoie le SIGTERMsignal au processus shell a été planifié (ou a été délivré) plus tard ou plus tôt que les write()appels système d' écho .

Mais cependant, le script s'arrête et le code de sortie n'est pas 0. Il devrait donc résoudre votre problème.

Une autre solution consiste, bien sûr, à utiliser des canaux nommés pour cela. Mais, cela dépend de la complexité de votre script pour implémenter des canaux nommés ou de la solution de contournement ci-dessus.

Les références:

• http://mywiki.wooledge.org/BashFAQ/106
• http://mywiki.wooledge.org/RaceCondition
• http://lists.gnu.org/archive/html/bug-bash/2010-09/msg00017.html

Pour mémoire, et même si les réponses et commentaires étaient bons et utiles, j'ai fini par implémenter quelque chose d'un peu différent (j'avais des restrictions sur la réception des signaux dans le processus parent que je n'ai pas mentionné dans la question)

En gros, j'ai fini par faire quelque chose comme ça:

command <(subcomand 2>error_file && rm error_file) <(....) ...

Ensuite, je vérifie le fichier d'erreur. S'il existe, je sais quelle sous-commande a échoué (et le contenu du fichier d'erreur peut être utile). Plus verbeux et hack que je voulais à l'origine, mais moins lourd que de créer des pipes nommées dans une commande bash à une ligne.

Cet exemple montre comment utiliser killavec trap.

#! /bin/bash
failure ()
{
  echo 'sub process failed' >&2
  exit 1
}
trap failure SIGUSR1
cat < <( false || kill -SIGUSR1 $$ )

Mais killne peut pas passer un code retour de votre sous-processus au processus parent.

De la même manière que vous implémenteriez $PIPESTATUS/ $pipestatusavec un shell POSIX qui ne le prend pas en charge , vous pouvez obtenir l'état de sortie des commandes en les passant via un tube:

unset -v false_status echo_status
{ code=$(
    exec 3>&1 >&4 4>&-
    cat 3>&- <(false 3>&-; echo >&3 "false_status=$?") \
             <(echo ok 3>&-; echo >&3 "echo_status=$?")
);} 4>&1
cat_status=$?
eval "$code"
printf '%s_code=%d\n' cat   "$cat_status" \
                      false "$false_status" \
                      echo  "$echo_status"

Qui donne:

ok
cat_code=0
false_code=1
echo_code=0

Ou vous pouvez utiliser pipefailet implémenter la substitution de processus à la main comme vous le feriez avec des shells qui ne le prennent pas en charge:

set -o pipefail
{
  false <&5 5<&- | {
    echo OK <&5 5<&- | {
      cat /dev/fd/3 /dev/fd/4
    } 4<&0 <&5 5<&-
  } 3<&0
} 5<&0