Discussion :

[Liamm]

Bonjour,

voici un appel à un shell-script à l'intérieur d'un shell-script:
Ce

Code :

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

1
2
cd /home/liam/projets/github_BSHELL/B_SHELL_WCC_NUM/
./ps0num.sh "$1" "$2"

fonctionne.

Comment lancer le script ps0num.sh sur une seule ligne (au lieu de deux) ?

[Sve@r]

Bonjour

Comment lancer le script ps0num.sh sur une seule ligne (au lieu de deux) ?

C'est quoi le "point" devant le nom du script que tu appelles? Réponse: c'est le dossier dans lequel se trouve le script.

Donc si le script ne se trouve pas dans le dossier "." mais dans un autre, ben tu indiques cet autre dossier lors de l'appel. Un simple effort de réflexion et d'associations d'idées te l'aurait fait déduire directement

[N_BaH]

ON N'UTILISE PAS ls cd DANS UN SCRIPT !!!

[Liamm]

@ Sve@r
Le

Code :

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

/home/liam/projets/github_BSHELL/B_SHELL_WCC_NUM/ps0num.sh "$1" "$2"

ne marche pas
.
.
@N_BaH

ON N'UTILISE PAS cd DANS UN SCRIPT !!!

Pourquoi . . . pas ?

[N_BaH]

il est préférable dans un script de toujours utiliser des chemins absolus, ce qui rend cd inutile.

si tu as des chemins très longs et/ou qui seront réutilisés dans le script, tu les mets dans une variable.

Code :

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

1
2
chemin='/mon/tres/long/chemin/ou/est/mon'
maCommande "$chemin/fichier"

il est d'ailleurs très rare d'être contraint de changer de répertoire dans un script pour qu'une commande s'exécute dans un environnement donné.

et aussi pour asticoter Sve@r.

[Sve@r]

Le /home/liam/projets/github_BSHELL/B_SHELL_WCC_NUM/ps0num.sh "$1" "$2" ne marche pas

Mets des guillemets dans tes chaines. C'est pas obligatoire tout le temps mais ça l'est dans le cas où un chemin contient un espace. De là, les mettre tout le temps permet de faire que ça marche tout le temps.
"/home/liam/projets/github_BSHELL/B_SHELL_WCC_NUM/ps0num.sh" "$1" "$2".
Accessoirement tu as la variable "$HOME" qui permet d'adapter tes scripts aux users qui les exécutent.
"$HOME/projets/github_BSHELL/B_SHELL_WCC_NUM/ps0num.sh" "$1" "$2".

et aussi pour asticoter Sve@r.

Un jour il y aura vengeance. Je ferai "shazam" et ton univers s'écroulera pour faire place au mien

[Liamm]

Merci N_BaH

Mon script va faire exécuter d'autres scripts,
chacun d'eux étant dans un environnement (répertoire) différent.

Ce que je ne comprends pas, c'est pouquoi
le

Code :

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

/home/liam/projets/github_BSHELL/B_SHELL_WCC_NUM/ps0num.sh "$1" "$2"

avec le chemin absolu, d'accès au sous-script, ne marche pas !

MODIFICATION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MODIFICATION
En fait, le script ps0num.sh ne s'exécute pas sous l'environnement /home/liam/projets/github_BSHELL/B_SHELL_WCC_NUM/
mais
sous celui où le script principal s'exécute ! (/home/liam/projets/github_BSHELL/B_SHELL_WAA_NUM/

[Liamm]

Merci Sve@r.

J'ai bien noté ton conseil de mettre des guillemets.

Cependant, mon chemin absolu ne comporte pas d'espaces.

En général, je remplace l'espace par l'underscore '_' que ce soit pour les noms de fichiers ou de répertoires.

[disedorgue]

Moi, je ne vois pas d'erreur dans l'executiion de ton script, c'est quoi le "ne marche pas" ?

[Sve@r]

Cependant, mon chemin absolu ne comporte pas d'espaces.

Ah oui, désolé j'ai pas vu les underscores

Donc je ne peux que retomber sur la question de disedorgue.

En fait, le script ps0num.sh ne s'exécute pas sous l'environnement /home/liam/projets/github_BSHELL/B_SHELL_WCC_NUM/

Le terme "environnement" ne s'applique pas pour des dossiers. Dans l'absolu, que tu sois dans un dossierX ou dossierY n'a aucune importance. Et si tu peux faire cd truc puis ./script.sh alors /truc/script.sh fonctionne tout pareil.

[Liamm]

Bonjour disedorgue.

Si je mets
Ce

Code :

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

1
2
cd /home/liam/projets/github_BSHELL/B_SHELL_WPP_EOO/
./ps0eto.sh "$1" "$2"

dans un script (maitre) que je lance dans cd /home/liam/projets/github_BSHELL/B_SHELL_WTT_EAA/ via ./ps0all.sh 23 27 (au terminal)
ça marche bien
.
.
.
Mais si je mets à la place
ce

Code :

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

/home/liam/projets/github_BSHELL/B_SHELL_WPP_EOO/ps0eto.sh "$1" "$2"

ça ne marche plus.
Car tout se passe comme si le programme ps0eto.sh s'exécutait dans un mauvais environnement (/home/liam/projets/github_BSHELL/B_SHELL_WTT_EAA)

J'ai essayé d'être clair, mais ça ne l'est peut-être pas tant que ça !

[disedorgue]

A quoi servent les paramètres et que fait le script en fait ?

[Sve@r]

Car tout se passe comme si le programme ps0eto.sh s'exécutait dans un mauvais environnement (/home/liam/projets/github_BSHELL/B_SHELL_WTT_EAA)

Non, c'est en réalité tout le contraire. Dans le second cas, tu n'as pas changé de dossier de départ.

Partons d'une situation : tu te trouves dans "/tmp" et tu appelles ./maitre.sh qui fait

Code bash :

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

1
2
cd /truc
./esclave.sh

Le script "esclave.sh" s'exécute dans le dossier "/truc". Si ce dossier "/truc" contient un fichier "fic", il peut le lire ou le traiter via un simple cat fic.

Si maintenant le script "maitre.sh" appelle /truc/esclave.sh, ça marche mais le script s'exécute cette fois dans "/tmp" (l'endroit où tu te trouves quand tu as appelé "maitre.sh"). Donc si le script "esclave.sh" fait son cat fic effectivement ça ne fonctionnera pas parce que le fichier "fic" ne se trouve pas dans "/tmp".

Mais si le script "esclave.sh" commence par echo coucou, dans les deux cas tu verras "coucou" apparaitre à l'écran, preuve que dans les deux cas, le script se lance parfaitement. Si ensuite dans un des cas il ne parvient pas à accéder à certains fichiers, alors c'est la faute de celui qui a codé "esclave.sh" qui traite "fic" sans prendre en considération l'endroit où on se trouve quand on l'appelle.

J'ai essayé d'être clair, mais ça ne l'est peut-être pas tant que ça !

En réalité si.

[N_BaH]

En fait, le script ps0num.sh ne s'exécute pas sous l'environnement /home/liam/projets/github_BSHELL/B_SHELL_WCC_NUM/
mais
sous celui où le script principal s'exécute ! (/home/liam/projets/github_BSHELL/B_SHELL_WAA_NUM/

il est préférable dans un script de toujours utiliser des chemins absolus

dans tous les scripts !

[Liamm]

Bonjour,

@disedorgue
$1 = 23 (pour la fin de l'année 2023)
$2 = 27 (numéro de semaine de l'année)
.
.
.
@Sve@r
Je comprends (du moins il me semble) :
Je lance le script ./ps0all.sh 23 27 depuis le terminal en étant positionné sur le répertoire REP01 qui contient ce script.

Ce script ./ps0all.sh 23 27 doit lancer 5 scripts se trouvant dans 5 répertoires différents:
script01 dans REP01
script02 dans REP02
script01 dans REP03
script02 dans REP04
script03 dans REP05
Les répertoires contiennent le même ensemble de programmes(scripts) mais des données différentes (c'est pour cela que je parlais d'environnements différents)
Autrement dit, les 5 répertoires contiennent les mêmes 3 scripts : script01, script02, script03 mais des données différentes.

Ainsi,
le

Code :

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

/home/chemin/absolu/REP03/script01

n'est pas équivalent
au

Code :

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

1
2
cd /home/chemin/absolu/REP03/
./script01

.
.
.
@N_BaH

il est préférable dans un script de toujours utiliser des chemins absolus

C'est vrai (dans l'absolu, si j'ose dire)
mais je me vois mal mettre un chemin absolu chaque fois que j'utilse un fichier ou une table, sans parler des progammes !
En effet, chacun de mes répertoires (REP01, REP02, REP0, REP04, REP05) contient plus de 100 fichiers.

[Sve@r]

Ainsi,
le

Code :

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

/home/chemin/absolu/REP03/script01

n'est pas équivalent
au

Code :

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

1
2
cd /home/chemin/absolu/REP03/
./script01

La position dans l'arborescence du process exécuté n'est pas la même. Ce qui a alors un impact si ce process doit accéder à des fichiers de l'arborescence et que ces fichiers sont nommés en relatif dans le script.
Suffit de faire un test. Un petit script "xxx.sh" contenant cette ligne echo "je me trouve dans $(pwd)" puis tu places ce "xxx.sh" dans le dossier "/tmp" que tu appelles de ces deux façons /tmp/xxx.sh puis cd /tmp; ./xxx.sh (en veillant, au départ, à ne pas être dans "/tmp" évidemment !!!) et tu verras que les affichages écrans ne sont pas les mêmes.
C'est très important, quand on crée un script qui doit manipuler des fichiers, de bien penser à l'endroit où l'utilisateur se trouvera quand il exécutera le script.

mais je me vois mal mettre un chemin absolu chaque fois que j'utilse un fichier ou une table, sans parler des progammes !
En effet, chacun de mes répertoires (REP01, REP02, REP0, REP04, REP05) contient plus de 100 fichiers.

Tu peux factoriser. Tu peux utiliser par exemple dirname "$0" pour récupérer le chemin du script en cours et utiliser ce chemin pour référencer tes fichiers par rapport au dossier du script. Tu as aussi "$HOME" qui contient le nom du dossier home de l'utilisateur qui appelle le script. Les 100 fichiers ne peuvent-ils pas être récupérés automatiquement depuis une boucle style for f in * au lieu d'être nommés un par un?

Faut être clair: à un moment donné dans la conception, et probablement assez haut, tu as raté un truc. Et ce "ratage" est descendu en cascade pour en arriver à cette situation où tu en conclues par "je me vois mal tout rattrapper". Mais quelque part il faudra quand-même tout rattrapper. Ou alors tu en restes à ce cd dossier_contenant_le_script; ./script qui fonctionne en espérant que ça ne repartira pas en pluie fine sur un autre truc.

[disedorgue]

pour le coup, je préfère realpath à dirname.

Code :

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

1
2
3
4
$ cat testdirname.sh 
#!/bin/bash
 
dirname "$0"

Code :

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

1
2
$ ./testdirname.sh 
.

Code :

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

1
2
3
4
$ cat testrealpath.sh 
#!/bin/bash
 
realpath "$0"

Code :

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

1
2
$ ./testrealpath.sh 
/home/disedorgue/testrealpath.sh

Après, realpath n'est pas un standart , donc il peut ne pas être installé d'office dans une release linux.

[Sve@r]

pour le coup, je préfère realpath à dirname.

En fait ça n'a pas d'importance. Avec dirname quand tu appelles le script de façon relative tu obtiens un chemin relatif mais ce chemin est quand-même valide et permet d'accéder aux fichiers voulus si ceux-ci ont une arborescence en lien avec le script.
Si par exemple le dossier contenant le script contient un fichier "fic", tu y accèderas parfaitement via $(dirname "$0")/fic quelle que soit ta façon d'appeler le script.
Après realpath peut être utile dans les affichages. C'est plus sympa de voir à l'écran "je vais traiter [/home/truc/projet]" que "je vais traiter [.]".

Après, realpath n'est pas un standart

Sur les distribs en ".deb" il est dans le paquet "coreutils" qui est installé par défaut (ce paquet contient d'ailleurs plein d'autres outils comme nohup, expr, du et aussi basename et dirname)

[disedorgue]

Pas tout à fait d'accord, quand ton script fait des modifications de fihiers (genre conf) contenant ces types de données, mettre un chemin relatif au lieu du chemin absolu peut avoir des conséquences.

[Sve@r]

quand ton script fait des modifications de fichiers (genre conf) contenant ces types de données, mettre un chemin relatif au lieu du chemin absolu peut avoir des conséquences.

Ah ok. Si tu enregistres le chemin du script pour y revenir lors d'un appel ultérieur, tu peux te retrouver avec un "ancien" chemin devenu ensuite invalide dans un autre contexte d'appel.
Mais là j'espère que tu admettras que c'est quand-même aller chercher super loin le cas extrême de l'extrême non ?