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

Citation:

---

Envoyé par Sve@r

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

---

J'ai déjà eu le cas, dans le contexte d'un script d'installation (très basique) pour une appli tiers qui devait configurer des chemins dans les fichiers de configuration de l'appli en question.

Merci pour vos réponses.
Je ne manquerai pas de les analyser et de les tester plus tard.
Car là, il fait déjà plus de 30°C et je n'en peux plus !

bonjour

Citation:

---

Envoyé par Liamm

Autrement dit, les 5 répertoires contiennent les mêmes 3 scripts : script01, script02, script03 mais des données différentes.

---

Si j'ai bien compris, tu as aussi un problème de conception à ce niveau parce que ici aussi, tu ne gères pas les chemins (ou mal).
Tu as donc à faire un changement dans ton architecture et d'en déduire des changements de codes dans ton script appelant et tes script(s?) appelé(s?)

Citation:

---

Envoyé par N_BaH

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

---

En dehors du fait qu'il y a des cas de figure où les cd et l'utilisation de chemins relatifs simplifie grandement la vie, je ne comprend pas pourquoi ça serait préférable d'utiliser des chemin absolus.

Citation:

---

Envoyé par Nb

je ne comprend pas pourquoi ça serait préférable d'utiliser des chemin absolus.

---

Parce que le chemin ne dépend alors pas de l'emplacement de celui qui appelle le script, ce qui simplifie beaucoup de problèmes. Si tu dois bosser sur "/var/apt" ben vaut mieux nommer ce chemin en absolu plutôt que "../../../../../../../../../../../../../../../../../../../var/apt" :aie:

Toutefois il peut arriver que le script soit dédié à un projet ; et donc ira travailler sur des fichiers du projet. Le script et les fichiers sont donc situés tous deux dans l'arborescence du projet. Dans ce cas, généralement je repère les fichiers par rapport à l'emplacement du script, en utilisant dirname "$0" déjà mentionné.
Cela permet au projet d'être déplacé ensuite n'importe où dans l'arborescence sans avoir à modifier le script. Tant que l'arborescence intrinsèque du projet ne change pas, ça fonctionne (bon sauf cas spécifique exposé par disedorgue mais qui doit être quand-même assez rare).
A ce moment là, si l'utilisateur appelle le script en relatif cela donne des chemins en relatifs (mais ça fonctionne) et si l'utilisateur appelle le script en absolu ça donne des chemins en absolus (et ça fonctionne aussi). Mais je ne sais pas trop comment nommer ce type de chemin...

Citation:

---

Envoyé par Sve@r

Parce que le chemin ne dépend alors pas de l'emplacement de celui qui appelle le script, ce qui simplifie beaucoup de problèmes. Si tu dois bosser sur "/var/apt" ben vaut mieux nommer ce chemin en absolu plutôt que "../../../../../../../../../../../../../../../../../../../var/apt" :aie:

Toutefois il peut arriver que le script soit dédié à un projet ; et donc ira travailler sur des fichiers du projet. Le script et les fichiers sont donc situés tous deux dans l'arborescence du projet. Dans ce cas, généralement je repère les fichiers par rapport à l'emplacement du script, en utilisant dirname "$0" déjà mentionné.
Cela permet au projet d'être déplacé ensuite n'importe où dans l'arborescence sans avoir à modifier le script. Tant que l'arborescence intrinsèque du projet ne change pas, ça fonctionne (bon sauf cas spécifique exposé par disedorgue mais qui doit être quand-même assez rare).
A ce moment là, si l'utilisateur appelle le script en relatif cela donne des chemins en relatifs (mais ça fonctionne) et si l'utilisateur appelle le script en absolu ça donne des chemins en absolus (et ça fonctionne aussi). Mais je ne sais pas trop comment nommer ce type de chemin...

---

Oui, donc rien de plus que du bon sens. Donc ce n'est pas comme essayer de parser le resultat d'un ls dans un script, là il n'y a aucune raison technique pour ne pas utiliser de cd tant que l'on sait ce que l'on fait.

Citation:

---

Envoyé par Nb

là il n'y a aucune raison technique pour ne pas utiliser de cd tant que l'on sait ce que l'on fait.

---

Tout à fait. J'essaye cependant de l'éviter autant que possible.
Et si je dois m'y résoudre, alors je préfère passer par pushd ce qui me permet, avec popd, de revenir ensuite à mon point d'origine.

Il est quand même très simple de passer le répertoire "de travail" au script via fichier.conf, paramètre au script, variable d'environnement…

De plus il est plus sécurisé d'utiliser toujours les chemins absolus :

Code:

---

1 2 3 4 5 6 7 8

travail="$HOME/workspace/datas series" cd "$travail" rm *.* # :aie: si le répertoire n'est plus accessible # ou même simplement extraire les fichiers d'une archive ou autre ...   travail="${1:-$HOME/workspace/datas series}" [[ "$travail" != $HOME* ]] && exit 2 rm "$travail/"*.* # pas de tragédie à l'horizon :)

---

EDIT: merci Sve@r , modifié

Citation:

---

Envoyé par papajoker

rm "${travail}/*.*" # pas de tragédie à l'horizon :)

---

Il y aura d'autant moins de tragédie à l'horizon que dans les doubles quotes, l'étoile n'est pas expandue :mrgreen:

Vérifie aussi travail="${1:-'~/travail'}" car je sens que les simples quotes vont avoir aussi un rôle assez important dans la gestion réussie (en fait pas) du tilde :oops: