BASH : reprise de contexte

Programmation
#1

Bonjour à tous,

Je cherche à utiliser une fonctionnalité de bash qui n’en est peut être pas une :
J’ai écrit deux scripts. Le premier exécute quelques commandes, lance le second puis exécute d’autres commande (rien d’extraordinaire jusque là). Le second script remplace ou édite le premier (un cp d’un troisième script pour mes tests).
Lorsque le premier script (qui est en fait un troisième script) reprend la main (à la fin de l’exécution du second) il reprend son exécution avec ses anciennes variables et ses nouvelles instructions.

Ma question est : comment est géré cette reprise? Est-ce que le système se souviens de la dernière ligne exécutée? Dans ce cas que se passe-t-il si j’ajoute des lignes en haut de mon fichier?

Je cherche donc a vraiment comprendre comment le système gère cette reprise, quelles sont ces limites, à quoi je vais devoir faire attention. Mon but est de développer des script qui apprennent et qui évoluent d’eux mêmes. Oui je pourrais le faire beaucoup plus facilement dans un autre langage, mais … disons que je suis maso (ou que j’aime le challenge).

D’avance merci.

Diégo

#2

salut,

lors de l’exécution d’un script, son contenu est lu, et placé en mémoire.
la modification du fichier, pendant l’exécution du script, ne modifiera pas ce qui est chargé en mémoire.
il faudrait lancer la version modifiée pour que les modifications soient prises en compte.

#3

Salut Watael,

Cela est le fonctionnement nominal pour UN script. Néanmoins si ce script en appel un autre, le contenu du script est effacé de la mémoire (pour gérer les appels récursifs par exemple). Ma question était donc comment le système gère la reprise du premier script. Je sais qu’il relit le script pour le recharger en mémoire, mais je ne sais pas comment il gère si le script a été modifié.

Pour info : ce que j’ai fait est quelque chose du genre : mon script définit une variable à “toto”, appelle un second script puis fait un echo “toto$VAR”. Néanmoins le second script remplace les toto par tata dans le premier script (un petit sed).
En sortie j’ai tatatoto.
Donc cela étaye bien ce que j’avance. Néanmoins je voudrais savoir ce qu’il se passe si la modification est plus impactante (ajout de lignes, suppression de la ligne appelant le second script, etc …)

Diégo

#4

:question:

pas chez moi :frowning:

$ cat script1 #!/bin/bash echo "nom script : $0" ./script2 var="bla bla" echo "$var" $ $ cat script2 #!/bin/bash sed -i 's/var="bla bla"/var="to to"/' script1 $ $ ./script1 nom script : ./script1 bla blalors des exécutions ultérieures, script1 affiche effectivement «to to», parce qu’alors j’exécute la version modifiée.

#5

Dans ton exemple rien d’exceptionnel, tu démarres un script qui en modfie un autre, au moment ou tu démarres le deuxième, il est modifié … Qu’est-ce qui t’amènes à te poser des questions ?

#6

Salult,

Bon je vois que j’ai mal exposé le pb et que j’ai fait une supposition erronée. J’avais simplifié mes scripts, pensant que ce la ne changeait rien, mais en fait si. Donc le cas que je décrivais ne se produis finalement qu’avec un scp. Voilà mon test qui permet de reproduire le comportement étrange.

cat script1.sh VAR=t0t0 ./script2.sh echo "t0t0 $VAR"

cat script2.sh scp -q localhost:./script/script3.sh script1.sh

cat script3.sh VAR=tata ./script2.sh echo "tata $VAR"

Et donc l’exécution produit cela.

./script1.sh tata t0t0

C’est en codant mes scripts que je me suis posé la question du cas au limite, et que j’ai découvert cette bizarrerie. Maintenant ma curiosité a été très attisée par cela et j’aimerais comprendre exactement ce qui se passe. Puisque dans mon utilisation ce cas va arriver, je voudrais pouvoir anticiper des comportements inattendu. Et pour le challenge technique, j’ai bien envie d’exploiter ce comportement (oui c’est inutile, mais bon …) pour faire une genre de code qui se réécrit lui même.

#7

euh, ouaip… en effet, c’est bizarre…
:119

#8

Ça me rappelle une histoire qui m’était arrivé avec un BATCH du [mono]DOS[/mono] : Langage interprété, tout comme [mono]bash[/mono].

Les instructions sont lues (interprétées) avant d’être exécutées => [mono]bash[/mono] reprends la lecture du script au caractère suivant l’instruction dont il vient de finir l’exécution

=======
Alors, en reprenant tes scripts [mono]script1.sh[/mono] et [mono]script2.sh[/mono] :

[quote=“contenu de “script1.sh””][mono]VAR=t0t0
./script2.sh
echo “t0t0 $VAR”[/mono]
[/quote][quote=“contenu de “script2.sh””][mono]scp -q localhost:./script/script3.sh script1.sh[/mono][/quote]
si tu modifie script3.sh comme ci-dessous,

[quote=“NOUVEAU contenu de “script3.sh””][mono]#…
#…
VAR=tutu
echo “tata $VAR”[/mono][/quote]et que tu exécute [mono]script1.sh[/mono], après l’écrasement par [mono]scp[/mono], [mono]bash[/mono] reprendra la lecture des instructions du [mono]script1.sh[/mono] (qui aura été écrasé par [mono]scp[/mono]) juste au [mono]V[/mono] de [mono]VAR[/mono]

Dans ce cas là, la variable [mono]$VAR[/mono] sera égale à [mono]tutu[/mono]

======
Dans ce [mono]script3.sh[/mono], ajoute 3 caractères sur une des lignes au dessus de “VAR=tutu”, et le message d’erreur sera : [mono]=tutu : commande introuvable[/mono]
Ou bien, ajoute 4 caractères sur une des lignes au dessus de “VAR=tutu”, et le message d’erreur sera : [mono]tutu : commande introuvable[/mono]
Ou bien, ajoute 5 caractères sur une des lignes au dessus de “VAR=tutu”, et le message d’erreur sera : [mono]utu : commande introuvable[/mono]

Dans ces trois cas, [mono]$VAR[/mono] sera égal à [mono]t0t0[/mono] (qui avait été défini dans [mono]script1.sh[/mono] avant que [mono]scp[/mono] ne le remplace par le contenu de [mono]script3.sh[/mono])

etc…

#9

Merci MicP, c’est l’info que je cherchais (et qui implique donc que je vais devoir faire très attention).
Néanmoins, cela ne correspond pas à ce qui se passe si on remplace le scp par un cp.
Peut être que si le script ne contient que des opérations très simple, il est gardé en mémoire et n’est pas relu. Allez savoir.

#10

de mon côté, j’observe ce comportement que ce soit avec scp' oucp’, mais pas avec `sed’.
pourquoi ?..

$ uname -r 3.2.0-4-amd64