Parce que ce les différente commandes d'un pipe sont éxécutées dans autant de sous-shells (des nouveaux processus si tu veux). Ton "read var3" positionne bien une variable var3, mais dans un de ces sous-shell, qui meure juste après, et qui n'affecte en rien l'environnement de ton script.
T'a déjà été donné la solution qui consiste à remplacer le read par une affectation avec var3=$(...). Bon, ça ça marche bien parceque tu fais un read tout simple. Mais juste pour ta culture, en Bash, une solution plus générique pour récupérer la sortie de commandes de sous-shells par une commande du shell principal serait d'utiliser ce genre de redirection là :
read a b c d <<<$(echo 192.128.1.1 | sed 's:\.:\n:g')
(heu bon, ouais, y'a moins moche pour faire ça, m'enfin c'est un exemple)
Oh, et puis aussi, si jamais t'es en Bash-3.0, sache que les expressions régulières sont supportées en natif, sans passer par grep, avec l'operateur '=~' et le tableau BASH_REMATCH pour les résultats. Par exemple:
[[ "${var1}" =~ "${var2}" ]] && var3=${BASH_REMATCH[0]}
Ça peut paraitre plus compliqué comme ça, mais franchement nan pas vraiment, et surtout c'est infiniment plus rapide, et ça compte si jamais ton truc est dans une boucle : répetée 10000 fois, la soluce avec $(...grep...) prend ici ~20 secondes (le fork de processus est qqch de coûteux), alors que celle là en prend ~0,2.
Bon et puis même si tu n'es pas en bash-3.0 et que donc tu n'a pas les regexp, n'oublies pas de jetter un oeil au paragraphe "Parameter Expansion" dans ton $(man bash), parceque ça aussi ça permet souvent d'éviter des grep ou des sed dans les cas simples. Je parle des opération du style varB=${varA%pattern} et compagnie.
# Le pourquoi
Posté par tgl . En réponse au message rediriger le résultat d'une commande vers une variable. Évalué à 7.
Parce que ce les différente commandes d'un pipe sont éxécutées dans autant de sous-shells (des nouveaux processus si tu veux). Ton "read var3" positionne bien une variable var3, mais dans un de ces sous-shell, qui meure juste après, et qui n'affecte en rien l'environnement de ton script.
T'a déjà été donné la solution qui consiste à remplacer le read par une affectation avec var3=$(...). Bon, ça ça marche bien parceque tu fais un read tout simple. Mais juste pour ta culture, en Bash, une solution plus générique pour récupérer la sortie de commandes de sous-shells par une commande du shell principal serait d'utiliser ce genre de redirection là :
read a b c d <<<$(echo 192.128.1.1 | sed 's:\.:\n:g')
(heu bon, ouais, y'a moins moche pour faire ça, m'enfin c'est un exemple)
Oh, et puis aussi, si jamais t'es en Bash-3.0, sache que les expressions régulières sont supportées en natif, sans passer par grep, avec l'operateur '=~' et le tableau BASH_REMATCH pour les résultats. Par exemple:
[[ "${var1}" =~ "${var2}" ]] && var3=${BASH_REMATCH[0]}
Ça peut paraitre plus compliqué comme ça, mais franchement nan pas vraiment, et surtout c'est infiniment plus rapide, et ça compte si jamais ton truc est dans une boucle : répetée 10000 fois, la soluce avec $(...grep...) prend ici ~20 secondes (le fork de processus est qqch de coûteux), alors que celle là en prend ~0,2.
Bon et puis même si tu n'es pas en bash-3.0 et que donc tu n'a pas les regexp, n'oublies pas de jetter un oeil au paragraphe "Parameter Expansion" dans ton $(man bash), parceque ça aussi ça permet souvent d'éviter des grep ou des sed dans les cas simples. Je parle des opération du style varB=${varA%pattern} et compagnie.