Discussion :

[zephyre]

Bonjour,

J'ai lu dans un pdf que j'ai trouvé en ligne, intitulé = introduction à la programmation bash, auteur Eric Sanchis.
J'ai très bien compris le problème qu'il y a avec les pipes.
C'est à dire que chaque commande présente dans un pipe crée un nouveau processus.
Fin du processus => destruction des variables du même processus.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a=bonjour
b=
echo $a | read b
echo $b # N'affiche rien

En revanche dans ce livre pour résoudre ce problème de transmission de donnée entre processus il propose comme solution la chaine jointe.

J'ai fait le script suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a=bonjour
b=
echo $a | read <<< "$b" # technique de la chaine jointe
echo $b # Affiche toujours rien

Donc je pense que l'auteur à commis une erreur.

Comment faire pour résoudre ce problème ?

[Sve@r]

Bonjour

Fin du processus => destruction des variables du même processus.

Donc il n'y a qu'à ne pas finir le processus tant qu'on a besoin de ses variables...

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
echo $a | (
	read b
	echo $b
)

pour résoudre ce problème de transmission de donnée entre processus

Il n'y a pas de problème de transmission de donnés entre processus, entre processus les données sont parfaitement transmises...

Donc je pense que l'auteur à commis une erreur.

Tu es sûr? As-tu bien compris la notion de redirection en entrée? Parce que là tu lis "$b" qui est vide !!! Et puis es-tu certain que dans le livre il y a encore un pipe? Parce que c'est le pipe qui génère le processus donc si pipe, alors tu retombes sur le cas de départ...
read b <<< "$a"

[zephyre]

Bonjour,

Je pense que tu t'es trompé Sve@r :
ton code bash :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
echo $a | (
	read b
	echo $b
)

Cette syntaxe indique que read b et echo b est exécuté dans le processus courant qui vient justement d'être nouvellement crée.
Donc c'est normal que ça fonctionne.
Si tu fais juste à la suite de ton code un petit echo $b tu verras qu'il n'y a rien dans la variable b.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
echo $a | (
	read b
	echo $b
)
echo $b # N'affiche rien

Donc il y a bien un problème de transmission des données entre les processus car c'est des nouvelles variables, des copies au moment de la création
de chaque nouveau processus.
Ce n'est pas la même référence donc tu n'écris pas sur la même variable.

[Sve@r]

Donc c'est normal que ça fonctionne.

Et... tu n'es pas content que cela fonctionne?

Si tu fais juste à la suite de ton code un petit echo $b tu verras qu'il n'y a rien dans la variable b.

Je sais (ça fait assez longtemps que je fais du shell!!!). D'où ma remarque "il n'y a qu'à ne pas finir le processus tant qu'on a besoin de ses variables". Ce qui sous-entend que le processus ne doit se terminer que (conjonction de subordination) quand on n'a plus besoin de ses variables

Donc il y a bien un problème de transmission des données entre les processus car c'est des nouvelles variables, des copies au moment de la création
de chaque nouveau processus.

Oui, c'est effectivement un corollaire de la notion d'indépendance des processus. Le nouveau processus ayant sa zone de mémoire indépendante de celle du père peut y créer les variables qu'il veut sans collision avec la zone de mémoire du père. Ce qui n'est un problème que pour celui qui veut un OS n'ayant pas d'indépendance entre processus (et tant pis si dans un tel OS un processus A de type virus peut aller alors modifier un processus B en lui faisant croire n'importe quoi)...

Ce n'est pas la même référence donc tu n'écris pas sur la même variable.

Ah? Tu voulais que les effets du fils puissent affecter les variables du père? Tu ne l'as pas précisé au départ. Ben non, ce n'est pas possible. C'est comme ça que le shell est conçu, c'est un des principes de base d'Unix.
Tu peux éventuellement "simuler" un retour en utilisant les commandes incluses...

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
fct() {
	echo "bonjour"
}
 
b="$(fct)"
echo "b=[$b]"

... mais cela reste limité à une variable (pour en modifier deux il faut deux fonctions différentes ou alors une fonction qui retourne une chaine formatée type csv que tu explose au retour). Bref ça reste un ersatz. Un fils ne peut pas influer sur son père. C'est le père qui choisit ce qu'il veut faire de son fils. C'est comme ça.

Mais encore une fois, dis-moi en quoi cela te pose un problème? On te pose les bases, tu les acceptes et ensuite tu fais avec, surtout qu'on peut parfaitement s'en sortir en faisant avec (ou même en faisant sans avec cet exemple qui fait sans processus fils via ce read b <<< "$a") !!!

[Flodelarab]

Bonjour

Zephyre, je soutiens totalement Sve@r. C'est drôle, quand tu fais read <<< "$b", tu remplis le contenu de la variable $REPLY avec le contenu de $b. Il y a donc 2 problèmes bien séparés :

• On alimente une variable qui ne sert jamais. ($REPLY)
• On utilise une variable vide pour l'alimenter. ($b)

Si tu espérais remplir $b, ta déception est prévisible.

[N_BaH]

il n'y a pas de problème de transmission : la valeur est bien transmise du echo au read. il y a un "problème" de persistance de contexte.
en effet, les variables créées/modifiées dans un sous-shell n'ont pas d'existence, ou ne sont pas modifiées, dans le processus parent.
comme l'a dit sve@r, il faut faire perdurer le sous-shell tant qu'on a besoin de ses variables avec des accolades (pas la peine de rajouter un sous-shell avec des parenthèses ).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$ echo "bla bla" | { : #on prolonge le contexte du sous-shell
    read v
    echo "$v"
}
bla bla
$ echo "$v"  # on est sorti du sous-shell
$ # $v n'existe pas dans le shell parent.

[Sve@r]

avec des accolades (pas la peine de rajouter un sous-shell avec des parenthèses ).

Il y a un moyen de voir les différences?
J'ai tenté...

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
echo $$
echo | (
	echo "parenthèses: $$"
)
echo | {
	echo "accolades: $$"
}

... mais ça n'a rien donné de concluant...

[disedorgue]

En fait, on peut faire persister le contexte, mais dans un script:
En ligne de commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ shopt -s lastpipe 
$ echo bob | read b
$ echo "b=$b"
b=

Depuis un script:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
$ cat sc1.bash 
#!/bin/bash
 
shopt -s lastpipe
echo bob | read b
echo "b=$b"
 
$ ./sc1.bash 
b=bob

Après, je ne conseille pas cette pratique

[kaitlyn]

Salut,

En effet, avec l'option shell lastpipe ça fonctonne mieux.

Pour essayer de répondre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
echo $$ $BASHPID
shopt -s lastpipe
 
echo $$ 'p' | (
    read v1
    echo $v1 $$ $BASHPID
)
echo v1:$v1
 
echo $$ 'a' | {
    read v2
    echo $v2 $$ $BASHPID
}
echo v2:$v2
 
echo $$ 'n' | read v3; echo $v3 $$ $BASHPID
echo v3:$v3

[N_BaH]

Il y a un moyen de voir les différences?

on sait que les parenthèses créent un sous-shell, quand les accolades n'en créent pas.

et oui, je compte les sous-shells.


je trouve les accolades sous-employées, alors je fais leur promotion.

[Sve@r]

on sait que les parenthèses créent un sous-shell, quand les accolades n'en créent pas.

Peut-être que le pipe suivi de parenthèses est un cas particulier qui ne crée qu'un sous-shell (et non deux)...

je trouve les accolades sous-employées, alors je fais leur promotion.

Oui au droit à la différence. Les accolades aussi ont le droit d'exister...

[Flodelarab]

Surtout quand ça évite de fermer des shells de façon intempestive

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

( commande && exit 0; )

[zephyre]

Merci les gars j'ai tout compris.
C'est l'auteur du PDF en ligne qui m'a induis en erreur.
Merci encore.
Juste une question avant que je ne clos le sujet :
Je comptais acheter ce livre, = https://www.amazon.fr/How-Linux-Work...18500408&psc=1

Pour parfaire mes connaissances du système Linux; j'ai l'impression que la littérature en anglais est mieux adapter pour apprendre l'informatique.
Qu'en pensez vous ?

[Sve@r]

Juste une question avant que je ne close (subjonctif présent) le sujet :

Pour parfaire mes connaissances du système Linux; j'ai l'impression que la littérature en anglais est mieux adaptée pour apprendre l'informatique.
Qu'en pensez vous ?

Qu'avant de payer un truc tu peux déjà t'orienter vers le gratuit (surtout concernant Linux) ; et que la littérature française n'a rien à envier à l'anglaise.