Discussion :

[Liamm]

Bonjour,

Peut-on lancer un script dans un autre script ?

Et si oui, comment faire ?

[N_BaH]

peut-on lancer une commande dans un script ?!

[Liamm]

Oui j'ai trouvé :

il ne faut pas écrire :

mon_shell_dans_un_autre_script.sh

mais :

./mon_shell_dans_un_autre_script.sh

[N_BaH]

le mieux est d'indiquer le chemin absolu du script, plutôt que le chemin relatif.

[Liamm]

Merci pour l'info N_BaH.
En général, je mets tous les sources d'un même projet dans le même répertoire dans le répertoire : /projets/nom_de_mon_projet

[Sve@r]

Bonjour

il ne faut pas écrire :

mon_shell_dans_un_autre_script.sh

mais :

./mon_shell_dans_un_autre_script.sh

En fait cela fait partie d'un domaine plus général qui est "comment appeler un script quand il ne se trouve pas dans un chemin connu du PATH" => réponse: il faut impérativement préciser le dossier où il se trouve (et "." étant un nom de dossier, cette façon d'écrire est alors admise).

le mieux est d'indiquer le chemin absolu du script, plutôt que le chemin relatif.

Je ne suis pas d'accord. Il n'y a pas de "meilleure façon" de nommer un fichier, il y a juste "différentes" façons. Le nommage par chemin absolu ainsi que par chemin relatifs sont deux méthodes licites et qui possèdent toutes deux des avantages et des inconvénients. Si par exemple demain le script change de place le nommage absolu montrera alors ses limites.

[N_BaH]

Si par exemple demain le script change de place, le nommage absolu relatif montrera alors ses limites.

pour pallier à tous les déplacements (des scripts dans l'arborescence (par mv), ou au sein du script dans l'arborescence (par cd)), il est préférable d'indiquer le chemin absolu (depuis la racine du système de fichiers) des fichiers utilisés, ou d'ajouter ces chemins au PATH.

le meilleur chemin est celui qui évite les embûches.

[Sve@r]

Si par exemple demain le script change de place, le nommage absolu relatif montrera alors ses limites.

Non non, c'est bien le chemin absolu qui montrera ses limites. Si mon scriptA se trouve dans "/projet/toto" et qu'il appelle un scriptB se trouvant lui dans "/projet/toto/work" de cette façon /projet/toto/work/scriptB.sh il s'agit d'un chemin absolu. Mais si demain le dossier change et devient (par exemple) "/projet/toto_v01" cette façon absolue de l'appeler montrera alors ses limites. Alors que s'il l'appelle de cette façon ./work/scriptB.sh cette façon relative continuera à fonctionner.

C'est vrai que bien souvent un nommage absolu est plus rapide, plus facile et plus séduisant ; tout comme le côté obscur de la Force. Et tout comme le côté obscur de la Force, il y aura des cas où ce nommage ne sera pas le plus fort. Après tout, pour installer QGis, la procédure indiquée est mkdir build-master; cd build-master; cmake .. (nom bien relatif) ce qui permet à cette manipulation de fonctionner quel que soit le nom du dossier qgis en cours...

pour pallier à tous les déplacements (...au sein du script dans l'arborescence (par cd...

C'est vrai que se déplacer au sein d'un script peut poser quelques difficultés pour ne pas se perdre. C'est pourquoi j'évite au maximum d'effectuer cette opération. Mais si celle-ci est nécessaire, et que dans ce script précis la meilleure option est de travailler en relatif, alors je me sors les doigts et veille à ne pas perdre mon chemin.

[N_BaH]

./work/scriptB.sh cette façon relative continuera à fonctionner.

à condition d'être dans le bon répertoire.

donc,
le chemin absolu ne fonctionne pas quand on déplace le script,
le chemin relatif ne fonctionne pas quand on se déplace dans l'arborescence (avant ou dans le cours du script).

[Flodelarab]

Bonjour

En général, je mets tous les sources d'un même projet dans le même répertoire

On se moque de l'endroit où tu les mets. L'important est l'endroit d'où tu les exécutes. Et si tu as mis des chemins relatifs, ton code ne marchera plus. C'est pourquoi il faut mettre le chemin absolu.

@Sve@r, @N_BaH, J'ai l'impression de voir deux experts Excel qui débattent entre A1 et $A$1. Les deux sont bien.

Enfin, il y a une solution qui n'a pas été évoquée : source ou .. Vous ne voyez pas la plus-value ? Essayez de faire un cd dossier sans sourcer ...
Pour en savoir plus,

Code :

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

help source

.

[N_BaH]

Enfin, il y a une solution qui n'a pas été évoquée : source ou ..

soit, mais le chemin du fichier sourcé, tu le mets en relatif ou en absolu ?

[Sve@r]

à condition d'être dans le bon répertoire.

Ah ben évidemment, le chemin relatif se base sur notre position. Corollaire, il ne fonctionne correctement que si notre position est correcte.
C'est évidemment une contrainte inhérente à son usage donc qu'il faut prendre en considération quand on utilise cette façon de nommer les fichiers. Cela faiisait partie des inconvénients à prendre en considération quand j'ai dit que tous deux possédaient des avantages et inconvénients.

@Sve@r, @N_BaH, J'ai l'impression de voir deux experts Excel qui débattent entre A1 et $A$1. Les deux sont bien.

Tu remarqueras que c'était exactement mon premier propos qui était justement qu'on ne pouvait pas dire "le mieux est..." (la phrase qui m'a fait intervenir). Et c'est pareil en Excel, parfois je travaille en A1, parfois en $A$1, et parfois en A$1 et parfois en $A1 selon mes besoins.

Enfin, il y a une solution qui n'a pas été évoquée : source ou .. Vous ne voyez pas la plus-value ? Essayez de faire un cd dossier sans sourcer ...

Ca c'est autre chose. Cette instruction a un but très particulier (qui d'ailleurs retombe dans le même débat à savoir comment appeler le script sourcé) et donc toute utilisation en méconnaissant son contexte d'utilisation conduira à un mauvas résultat. Si par exemple le sous-script possède ses propres variables qui (malchance) ont le même nom que celles du script principal (et que le PO veut garder l'indépendance des espaces de travail) cette instruction va tout pêter.
Sinon effectivement cd dossier dans un sous-script appelé de façon classique ne se répercutera pas dans le script appelant. C'est dû au principe de séparation des processus. Ceci dit j'avais fait remarquer aussi que j'essayais autant que possible d'éviter du cd dans mes scripts car les soucis que ça engendre sont légion.

[disedorgue]

Ce que l'on peut faire aussi, c'est d'établir une règle, du genre :
-J'ai une arborescence stricte mais pas absolu depuis la racine comme par exemple:
dir1
dir1/bin
dir1/usr/bin
...
Et le script principal (celui qu'on lance et qui lance les autres) identifie le chemin absolu depuis ou il est executé et de là on sait où se trouvent les autres script à exécuter.

Par exemple, le script en question se trouve dans "dir1/usr/bin" , donc pour remonter sur dir1, on doit remonter de 2 crans, donc on aura dans le script lui même:

Code :

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

1
2
3
4
5
$ cat s1.bash
#!/usr/bin/bash
 
ABSDIR1=$(realpath ${0%/*}/../..)
echo $ABSDIR1

Et si on l'execute, depuis n'importe où:

Code :

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

1
2
3
4
5
6
7
$ pwd
/tmp/dir1/usr/bin
$ ./s1.bash 
/tmp/dir1
$ cd ../..
$ ./usr/bin/s1.bash 
/tmp/dir1

Après, il est vrai que realpath n'est pas toujours installé, mais on peut toujours utiliser un one liner perl ou python:

Code :

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

perl -MCwd -e 'print Cwd::realpath($ARGV[0]),qq<\n>' ${0%/*}/../..

Code :

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

python -c "import os,sys; print(os.path.realpath(sys.argv[1]))" ${0%/*}/../..

Ou créer une fonction qui exploite pwd pour obtenir le chemin absolu (je le laisse en exercice )

[jack-ft]

Oui j'ai trouvé :

il ne faut pas écrire :

mon_shell_dans_un_autre_script.sh

mais :

./mon_shell_dans_un_autre_script.sh

Si, si, on PEUT très bien écrire mon_shell_dans_un_autre_script.sh ...

à condition d'avoir pris la précaution d'adapter PATH:

Code :

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

PATH=$PATH:chemin_vers_mon_shell_dans_un_autre_script

... de préférence avec un chemin absolu...