Citation
|/|BaH
C'est beaucoup de finesse, voire de "ténuité".
J'avoue avoir du mal à saisir la différence.
J'observe effectivement des différences de
comportement des scripts selon le mode de
lancement, mais ça rentre pas dans cette bille de
bois dur qui me sert de tête...
J'ai cherché, suite à tes commentaires, des
explications, mais nib. Hormis le lien
précédemment cité. Je n'ai peut-être pas su
trouver les mots pour charmer Google...
Il faut bien comprendre que dans Unix, dès que tu demandes une exécution de code (ls, date, grep, script.sh) ton shell lance un sous-shell.
- Le shell dans lequel tu travailles se met en mode "attente"
- Le sous-shell a la charge d'exécuter le "ls", le "date", le "grep" ou le "script.sh"
Dès qu'il a fini, il disparait et le shell qui était en attente (le tien) reprend la main
Tout ça c'est transparent mais ce mécanisme permet de
- lancer une exécution en arrière plan (avec "&" en fin de ligne) => ton shell n'attend plus la fin de l'autre
- lier les différents codes via des pipes => ls |more => chaque commande est exécutée dans un shell bien distinct et le premier reverse sa sortie dans le second
Problèmatique => toute la mémoire allouée pour le code, le script, disparait lorsque le script se termine et ton shell courant ne récupère rien. Mais est-ce vraiment un problème ???
En revanche, demander un ". script" ou "source script" demande au shell courant de ne pas dédier le script à un autre => toutes les variables restent au niveau de ton shell
Démo => tu crées un script "toto.sh" qui contient le code suivant
#!/bin/sh
a="Salut"
echo $a
Puis tu lances "./toto.sh" et ensuite tu tapes "echo $a" => tu n'auras rien
Ensuite tu lances "source ./toto.sh" et ensuite tu tapes "echo $a" => tu obtiendras "salut"
L'homme qui murmurait à l'oreille des pingouins
[
fr.lang.free.fr]