Comme le montre la colorisation bash de linuxfr. Dans ce cas, comme la variable pid ne contiendra jamais d'espace, il n'y a pas de risque. Mais dans d'autre cas, ça risque de merder.
Je vais supposer que pidcontient une chaîne avec espace (ou séparateur contenue dans la variable IFS)
$ name="$(cat "/proc/${pid}/comm")"# Ligne initiale$ name=$(cat /proc/1 2/comm)#bash élimine le premier étage de guillemet et la variable.
Ensuite, il évalue la commande cat avec ses deux arguments : /proc/1 et 2/comm.
ce que tu voulais faire :
$ name="$(cat \"/proc/${pid}/comm\")"$ name=$(cat "/proc/1 2/comm")#bash élimine les guillemet et interprête \" en ".
Là, bash évalue ensuite cat avec 1 argument /proc/1 2/comm.
J'ai gardé ton exemple, qui n'est pas pertinent pour les espaces puisque les pid ne contiennent jamais d'espace. Néanmoins, lorsque l'on parse des éléments dans des répertoires cela arrive.
[^] # Re: Intéressant tes critiques sur le shell
Posté par Anthony Jaguenaud . En réponse au journal Sur systemd, btrfs & co. Évalué à 2.
Tes guillemets sont mal placés.
Comme le montre la colorisation bash de linuxfr. Dans ce cas, comme la variable
pidne contiendra jamais d'espace, il n'y a pas de risque. Mais dans d'autre cas, ça risque de merder.Je vais supposer que
pidcontient une chaîne avec espace (ou séparateur contenue dans la variableIFS)Ensuite, il évalue la commande
catavec ses deux arguments :/proc/1et2/comm.ce que tu voulais faire :
Là,
bashévalue ensuitecatavec 1 argument/proc/1 2/comm.J'ai gardé ton exemple, qui n'est pas pertinent pour les espaces puisque les pid ne contiennent jamais d'espace. Néanmoins, lorsque l'on parse des éléments dans des répertoires cela arrive.