Exécution d'un shell placé dans un répertoire différent du répertoire courant

Version imprimable

Voir 40 message(s) de cette discussion en une page

08/07/2023, 14h10
Liamm

Exécution d'un shell placé dans un répertoire différent du répertoire courant
Bonjour,

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

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) ?
08/07/2023, 15h08
Sve@r

Bonjour

Citation:

Envoyé par Liamm

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 :roll:
08/07/2023, 17h41
N_BaH

Citation:

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

:ptdr:
08/07/2023, 17h54
Liamm

@ Sve@r
Le

Code:

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

ne marche pas
.
.
@N_BaH

Citation:

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

Pourquoi . . . pas ?
08/07/2023, 18h09
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:

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. :mouarf:
08/07/2023, 18h25
Sve@r

Citation:

Envoyé par Liamm

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".

Citation:

Envoyé par N_BaH

et aussi pour asticoter Sve@r. :mouarf:

Un jour il y aura vengeance. Je ferai "shazam" et ton univers s'écroulera pour faire place au mien :kill:
08/07/2023, 18h32
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:

/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/
08/07/2023, 18h40
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.
08/07/2023, 18h58
disedorgue

Moi, je ne vois pas d'erreur dans l'executiion de ton script, c'est quoi le "ne marche pas" ?
08/07/2023, 19h22
Sve@r

Citation:

Envoyé par Liamm

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.

Citation:

Envoyé par Liamm

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.
08/07/2023, 19h35
Liamm
Bonjour disedorgue.

Si je mets
Ce
Code:

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:

/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 !
08/07/2023, 19h39
disedorgue

A quoi servent les paramètres et que fait le script en fait ?
08/07/2023, 19h47
Sve@r
Citation:

Envoyé par Liamm

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:

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.

Citation:

Envoyé par Liamm

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

En réalité si.
08/07/2023, 20h16
N_BaH

Citation:

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/

Citation:

Envoyé par NBaH

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

dans tous les scripts !
09/07/2023, 08h54
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:

/home/chemin/absolu/REP03/script01

n'est pas équivalent
au
Code:

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

Citation:

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.
09/07/2023, 09h15
Sve@r
Citation:
Envoyé par Liamm

Ainsi,
le

Code:

/home/chemin/absolu/REP03/script01

n'est pas équivalent
au

Code:

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.

Citation:

Envoyé par Liamm

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.
09/07/2023, 10h55
disedorgue
pour le coup, je préfère realpath à dirname.
Code:

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

1 2 $ ./testdirname.sh .
Code:

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

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.
09/07/2023, 11h12
Sve@r

Citation:

Envoyé par disedorgue

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 [.]".

Citation:

Envoyé par disedorgue

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)
09/07/2023, 11h35
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.
09/07/2023, 13h37
Sve@r

Citation:

Envoyé par disedorgue

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 :wow:?

Voir 40 message(s) de cette discussion en une page