Codes de sortie de find et xargs : le 0/>0 grossier de find face à l'échelle 123-127 de xargs

Ce que c'est

Le manuel de find reste volontairement vague dès qu'il s'agit d'autre chose qu'un booléen : « find exits with status 0 if all files are processed successfully, greater than 0 if errors occur. This is deliberately a very broad description. » (find se termine avec le statut 0 si tous les fichiers ont été traités avec succès, avec un statut supérieur à 0 en cas d'erreur ; la description est volontairement très large). Il ajoute une mise en garde réellement importante : en cas de sortie non nulle, « you should not rely on the correctness of the results of find » (il ne faut pas se fier à l'exactitude des résultats de find) — certains points de départ, ou certaines invocations -exec ... {} + en attente, peuvent ne jamais avoir été exécutés.

xargs est beaucoup plus précis sur la manière dont la commande invoquée a échoué :

Code	Signification
0	succès (et toutes les commandes lancées par xargs ont aussi terminé avec 0)
123	au moins une invocation de la commande s'est terminée avec un statut autre que 0 ou 255
124	la commande s'est terminée avec le statut 255 (xargs cesse alors de lire l'entrée)
125	la commande a été tuée par un signal
126	la commande ne peut pas être exécutée (trouvée mais non exécutable)
127	la commande est introuvable
1	une autre erreur est survenue (dans xargs lui-même)

Le manuel apporte un détail technique qui compte pour le scripting : les commandes lancées par xargs sont démarrées directement avec execvp(), sans passer par un shell ; ainsi, « the shell's (128 + signal) convention for reporting that a process had been killed by a signal is not used by xargs » (la convention du shell, 128 + signal, pour signaler qu'un processus a été tué par un signal n'est pas utilisée par xargs). Le code 125 est le code propre à xargs pour ce cas, et non 128+signal.

Pourquoi c'est important

Un schéma courant, find . -name '*.log' | xargs rm, mélange le « quelque part, quelque chose a échoué » grossier de find avec l'échelle précise de xargs. Une erreur de permission sur un sous-répertoire fait quitter find avec un code non nul (alors qu'il a quand même transmis à xargs tous les fichiers qu'il pouvait lire), tandis qu'un seul fichier cible illisible passé à rm apparaîtrait via le code 123 de xargs (sortie non nulle ordinaire), et pas du tout via le code de find. Les deux échecs sont signalés de façon totalement indépendante, et un pipeline qui ne vérifie que le $? de la dernière commande ne voit que la partie de l'histoire qui concerne xargs.

Comment l'appliquer

• Après find | xargs, vérifiez les deux codes de sortie si le shell ou le pipeline le permet (pipefail et PIPESTATUS de bash) ; un find non nul accompagné d'un xargs à zéro signifie que certains fichiers n'ont jamais été listés, sans aucun signalement.
• Considérez un code non nul de find comme « les résultats peuvent être incomplets », et pas seulement comme « une erreur a été journalisée » ; relancez avec des diagnostics -print/-ls ou des points de départ plus restreints pour déterminer ce qui a été ignoré.
• Pour xargs, traitez 126/127 comme des problèmes de configuration (mauvais nom ou chemin du binaire), et 123/124/125 comme des problèmes liés à des invocations individuelles d'une commande par ailleurs correcte.
• Utilisez find ... -print0 | xargs -0 ... lorsque des noms de fichiers peuvent contenir des espaces ou des retours à la ligne, indépendamment de la question des codes de sortie.

Pièges

• Croire que le code de sortie de find indique quel fichier ou répertoire a échoué : ce n'est pas le cas, il faut examiner sa sortie d'erreur (stderr).
• Croire que le 125 de xargs suit la numérotation 128+signal du shell ; le manuel indique explicitement que ce n'est pas le cas.