Commande shell sans opération qui préserve $?

Il n'est certainement pas possible dans un shell compatible POSIX d'écrire une commande qui ne touche pas $? . En lisant la norme IEEE 1003.1-2017 vol. 3 chapitre 2 «Shell Command Language», nous apprenons que:

• §2.8.2 indique que «[chaque] commande a un statut de sortie» (donc aucune commande n'a pas de statut de sortie).
• §2.5.2 «Paramètres spéciaux» dit que $? «[e] xpands à l'état de sortie décimal du pipeline le plus récent (voir Section 2.9.2)».
• §2.9.2 «Pipelines» indique qu'un pipeline est une séquence d'une ou plusieurs commandes, éventuellement précédée (dans son ensemble) par ! , avec des commandes jointes par | . À propos de l'état de sortie, il dit

  Si le pipeline ne commence pas par le ! réservé, l'état de sortie doit être l'état de sortie de la dernière commande spécifiée dans le pipeline. Sinon, l'état de sortie doit être le NON logique de l'état de sortie de la dernière commande.

• §2.9 «Shell Commands» définit une «commande» et dit que «[u] nsauf indication contraire, le statut de sortie d'une commande sera celui de la dernière commande simple exécutée par la commande». ™. Une «commande» peut être l'une des suivantes:
  • Une commande simple (§2.9.1), qui est simplement un programme externe, un shell intégré ou une affectation de variable (sans nom de commande). Le premier retournera bien sûr l'état de sortie de la commande exécutée. À propos de ce dernier, la spécification dit:

    S'il n'y a pas de nom de commande, mais que la commande contenait une substitution de commande, la commande doit se terminer avec l'état de sortie de la dernière substitution de commande effectuée. Sinon, la commande doit se terminer avec un état de sortie nul.

  • Un pipeline, décrit par le §2.9.2 mentionné ci-dessus.
  • Une liste composée (§2.9.3), qui est une séquence d'une ou plusieurs {séquences d'un ou plusieurs {séquences d'un ou plusieurs pipelines (voir ci-dessus), jointes par && ou || }, chacun terminé par ; ou & (avec un final ; facultatif)}, joint par des caractères de nouvelle ligne. Une liste composée renvoie l'état de sortie du dernier pipeline exécuté de manière synchrone; Les pipelines exécutés de manière asynchrone (ceux terminés par & ) définissent l'état de sortie sur zéro. Aucune des séquences ne peut être vide, ce qui garantit qu'au moins un pipeline sera exécuté.
  • Une commande composée (§2.9.4), qui est soit:
    • Un sous-shell ou une liste composée accolée (§2.9.4.1), qui renvoie l'état de sortie de la liste composée sous-jacente (voir ci-dessus).
    • Une construction conditionnelle ( case , §2.9.4.3 ou if , §2.9.4.4) ou une boucle ( for , §2.9.4.2; while , §2.9.4.5; until , §2.9.4.6). Si le corps de cette construction n'est pas exécuté, elle renvoie un statut de sortie nul.
  • Une définition de fonction (§2.9.5), qui renvoie un état de sortie de zéro si la définition est acceptée, et un état différent de zéro dans le cas contraire.
• Et enfin, §2.9.4.4 «La construction conditionnelle if» définit la condition et le corps de la construction if comme étant une liste composée, décrite par le §2.9.3 mentionné ci-dessus. Cela signifie que le corps d'une construction if contiendra toujours au moins une commande qui écrasera $? . La spécification ne laisse même aucune marge de manœuvre pour le «comportement défini par la mise en œuvre».

Tout ce qui précède signifie que la seule façon d'écrire une commande no-op qui préserve $? est en lisant la valeur en $? et le renvoyer. Il y a trois constructions dans le shell POSIX qui en sont capables, dont deux sont déjà mentionnées dans le corps de la question: une exit d'un sous-shell ou une invocation de fonction.

Le troisième est . : la déclaration d'approvisionnement en shell mentionnée dans la réponse de @ Jens. En recherchant un script contenant juste un return "$?" commande, la valeur de $? peuvent être préservés. Cependant, cela vous oblige à faire en sorte qu'un script approprié soit trouvé à un emplacement connu, ce qui, je suppose, est tout aussi gênant que de s'assurer qu'une fonction no-op a été définie suffisamment tôt dans le fichier (sinon plus).

Si vous pliez un peu l'exigence stricte de POSIX, même cela peut être surmonté:

. /dev/stdin <<EOF
return "$?"
EOF

/dev/stdin n'est pas une fonctionnalité POSIX, mais est largement disponible; il est explicitement répertorié dans IEEE Std 1003.1-2017 vol. 1 §2.1.1 comme extension. L'extrait ci-dessus a été testé pour fonctionner dans bash 5.0.8, dash 0.5.11 et busybox sh 1.30.1 sous Linux (avec une configuration /dev appropriée et ainsi de suite).

Le plus simple serait d'utiliser une simple mission. Au lieu d'utiliser : , do _rc=$? .

if condition; then
   [ list-true ]     # optional 
   _rc=$?
else
   [ list-false ]    # optional
   _rc=$?
fi
( exit $_rc )        # optional
list-post-if

En utilisant cette variable _rc , vous avez stocké l'état de sortie de la dernière commande exécutée, qu'il s'agisse d'une condition ou de la dernière commande dans list-true ou list-false .

• Les arguments en faveur de cette méthode sont la faible surcharge d'une affectation.
• L'argument contre est le besoin d'au moins réécrire list-post-if pour utiliser _rc au lieu de $? .
• Si ce dernier n'est pas possible, ou trop fastidieux, vous pourriez envisager d'ajouter un (exit $_rc) juste après l'instruction conditionnelle. Ceci, cependant, nécessite un sous-shell, mais ce n'est qu'un seul.

Ne laissez personne vous dire qu'il n'y a que des fonctions et des sous-shells.

Pouvez-vous créer ou distribuer un autre petit fichier? Si tel est le cas, vous pouvez créer un fichier avec juste

cat > keepstatus.c <<EOF
#include <stdlib.h>
int main(int argc, char **argv) {
    return argv[1] ? atoi(argv[1]) : 0;
}
EOF
$CC -o keepstatus keepstatus.c

puis source-le comme une commande "vide" gardant l'état de sortie:

$ echo 'return $?' > keepstatus
$ ls foobar
ls: fooobar: No such file or directory
$ . ./keepstatus
$ echo $?
2
$ sleep 100
^C
$ . ./keepstatus
$ echo $?
130

Ne bifche pas, n'utilise pas de fonctions, pas de variable supplémentaire, garde le statut et est aussi POSIXly que possible.

Il y a même une quatrième façon dont je peux voir, lorsque je sacrifie les points bonus pour avoir bifurqué et supposé, puisque vous êtes dans le territoire autoconf m4, que trouver et utiliser un compilateur hôte est un jeu d'enfant.

return $?

Ensuite, utilisez /path/to/keepstatus $? .