Discussion :

[disedorgue]

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 ?

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.

[Liamm]

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 !

[papajoker]

bonjour

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

[Nb]

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.

[Sve@r]

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"

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

[Nb]

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"

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.

[Sve@r]

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.

[papajoker]

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 :

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

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é

[Sve@r]

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

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