Pourquoi le résultat de wc -l est différent s'il est exécuté en backticks ?

Question

Je viens de constater que la sortie de wc -l diffère selon qu'elle est appelée directement ou entourée de guillemets. Par exemple :

pgrep bash | wc -l

donnerait 1, car il y a un processus bash en cours d'exécution. Mais en mettant cette commande entre parenthèses

echo `pgrep bash | wc -l`

J'ai d'abord pensé que les backticks ouvriraient un nouveau processus bash, mais

echo `pgrep bash`

ne trouve que le même processus que ci-dessus. Il en est de même lorsque l'on enferme la commande dans $() :

echo $(pgrep bash | wc -l)

Cela produira également 2. Quelqu'un sait-il pourquoi il en est ainsi ?

Answer 1

C'est à @cularis que revient tout le mérite, puisqu'il l'a posté en commentaire (juste) avant que j'aie eu le temps de le poster en réponse.

Apparemment

pgrep bash | wc -l

ne crée pas un nouveau processus bash ; il est capable d'invoquer pgrep bash y wc -l depuis le processus bash original directement.

Mais

echo `pgrep bash | wc -l`

fait créer un nouveau processus bash à cause du pipe (un nouveau processus est le moyen le plus simple de gérer toutes les redirections d'E/S et la gestion des processus nécessaires à l'exécution de l'option | imbriqués dans les backticks). Donc, dans ce cas, pgrep bash voit le processus bash nouvellement créé utilisé pour gérer le pipe, en plus du processus original (interactive/) utilisé pour exécuter la commande.

Essayez

pgrep bash

y

echo `pgrep bash | cat`

En regardant très rapidement la documentation de bash ( info bash (section 3.5.4, Substitution de commande) Je ne vois rien qui indique quand il crée un nouveau processus et quand il ne le fait pas.

Answer 2

Merci pour votre aide. J'ai en fait trouvé une meilleure solution. Au lieu d'utiliser wc -l, j'aurais dû utiliser l'argument -c, qui n'affiche que le nombre de processus correspondants. Eh bien, RTFM encore. ;-)