Chemin absolu ou cd

Bonjour,

J'ai une petite réflexion dans mon boulot , on a des script KSH où l'on fait appelle à d'aures script, mais la où je bosse il veulent faire un cd pour se retrouver dans le répertoire courant du script afin de le lancer:
Environnement Prod unix

Code:

---

1 2 3

#!/bin/ksh   cd /usr/bin/dev/; /monscript.ksh

---

Moi je pense qu'il vaut mieux lancer une seul instruction :

Code:

---

1 2 3

#!/bin/ksh   /usr/bin/dev/monscript.ksh

---

Pour vous lequel est plus optimisé ou plus efficace ?:)

Merci pour vos lumières

Si des scripts doivent être enchaînés la méthode est carrément mauvaise.
il faut alors utiliser un ordonnanceur ou faire faire des levées de FLAGS aux scripts qui les attendent...

quand à l'utilisation d'un

cd truc ; machin.ksh c'est aberrant...

Citation:

---

Envoyé par frp31

quand à l'utilisation d'un

cd truc ; machin.ksh c'est aberrant...

---

Je suis d'accord aussi, principalement parce que le controle n'est quasiment jamais fait :

Code:

---

1 2 3 4 5 6 7 8 9

## On va executer machin cd toto/titi ./machin.ksh   ## On revient cd ../..   ## On fait autre chose ./autre_chose

---

Execution 1, depuis /home/moi, avec les repertoires toto et titi qui existent et qui ont les bons droits : pas de soucis.
Execution 2, depuis /home/moi, sans le repertoire toto : le cd ../../ va faire tres mal.

et le fait de tester que tu es dans le bon repertoire est beaucoup plus lourd que d'appeler le script avec le chemin absolu.

Citation:

---

Envoyé par gangsoleil

Je suis d'accord aussi, principalement parce que le controle n'est quasiment jamais fait :

Code:

---

1 2 3 4 5 6 7 8 9

## On va executer machin cd toto/titi ./machin.ksh   ## On revient cd ../..   ## On fait autre chose ./autre_chose

---

Execution 1, depuis /home/moi, avec les repertoires toto et titi qui existent et qui ont les bons droits : pas de soucis.
Execution 2, depuis /home/moi, sans le repertoire toto : le cd ../../ va faire tres mal.

et le fait de tester que tu es dans le bon repertoire est beaucoup plus lourd que d'appeler le script avec le chemin absolu.

---

JE suis daccord avec vous pour le chemin absolue sans utiliser le CD est bien meilleur , mais n'ayant pas la science infuse je cherchais des arguments ...merci beaucoup

Citation:

---

Envoyé par jojo971

je cherchais des arguments ...merci beaucoup

---

La programmation defensive, il n'y a que ca de vrai : tu fais quelque chose, tu verifies que ca a fonctionne avant de faire la chose suivante.

Donc pour tes collegues :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

cd toto res=$(echo $?)   if [ $res -eq 1 ] then echo "le repertoire n'existe pas " ## bon bah euh, on quitte exit -1 fi   ./script.sh res=$(echo $?)   if [ $res -eq 1 ] then echo "le script a echoue " ## bon bah euh, on quitte exit -1 fi

---

Pour toi :

Code:

---

1 2 3 4 5 6 7 8 9

/home/user/toto/script.sh res=$(echo $?)   if [ $res -eq 1 ] then echo "le script a echoue " ## bon bah euh, on quitte exit -1 fi

---

Tu gagnes du temps, tu passes par la case depart, tu gagnes un cafe, et tu es content. :)

Citation:

---

Envoyé par jojo971

Bonjour,

J'ai une petite réflexion dans mon boulot , on a des script KSH où l'on fait appelle à d'aures script, mais la où je bosse il veulent faire un cd pour se retrouver dans le répertoire courant du script afin de le lancer:
Environnement Prod unix

Code:

---

1 2 3

#!/bin/ksh   cd /usr/bin/dev/; /monscript.ksh

---

Moi je pense qu'il vaut mieux lancer une seul instruction :

Code:

---

1 2 3

#!/bin/ksh   /usr/bin/dev/monscript.ksh

---

Pour vous lequel est plus optimisé ou plus efficace ?:)

Merci pour vos lumières

---

Je suppose qu'il y a une coquille et qu'il manque un "." devant /monscript.ksh

La question de savoir si le script est trouvé est pertinente et on peut la régler par un test (que ce soit en absolu ou en relatif):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#!/bin/ksh typeset script=/usr/bin/dev/monscript.ksh if [[ ! -x "${script}" ]] ; then print "impossible d'exécuter ${script}" exit 1 fi typeset -i res ${script} ; res=$? if [[ $res -eq 0 ]] ; then : # ok else print "une erreur s'est produite pendant l'exécution de ${script}" # ici, on peut continuer ou arrêter... exit $res fi

---

Évidemment, ça améliore plus la robustesse que l'efficacité ou la lisibilité!


Amha, les outils doivent être organisés pour être trouvables dans le PATH.

Éventuellement, pour un outil inhabituel, il peut être désigné par son répertoire absolu (en faisant attention à la gestion des versions (ln vxxx -> current)).


Mais, surtout, il ne faut pas oublier qu'il y a une grande différence entre "cd" ou pas "cd": c'est que le répertoire courant n'est pas le même! (tautologiquement parlant!)

Si le script appelé traite des fichiers non globaux (dont le nom ne commence pas par "/"), il ne trouvera pas les mêmes suivant qu'on fait ou non un "cd"!

De même, si on passe des fichiers en argument au script, même problème!
${script} *.txt est très différent de cd some/where; ${script} *.txt.

Pour moi, si on choisit de faire un "cd", c'est pour se positionner à l'endroit où on veut lire ou modifier des fichiers.

Un script peut d'ailleurs nécessiter d'être lancé depuis un répertoire donné et s'attendre à y trouver une arborescence donnée (fichiers de config, fichiers de données, outils locaux, etc.).

En revanche, s'il doit lancer d'autres outils, le script doit pouvoir soit les trouver dans le PATH, soit pouvoir les désigner globalement, soit les trouver dans l'arborescence courante (si elle contient des outils locaux), mais ne doit en aucun cas reposer sur le fait qu'il est lancé depuis le répertoire où il est installé.

)jack(

Citation:

---

Envoyé par gangsoleil

La programmation defensive, il n'y a que ca de vrai : tu fais quelque chose, tu verifies que ca a fonctionne avant de faire la chose suivante.

---

Tout-à-fait d'accord!
(On est même en train de développer un framework pour ça)

Citation:

---

Code:

---

1 2	cd toto res=$(echo $?)

---

---

Pourquoi passes-tu par "echo"??? Y a-t-il une différence avec ceci:

Code:

---

1 2	cd toto res=$?

---

Citation:

---

Envoyé par jack-ft

Amha, les outils doivent être organisés pour être trouvables dans le PATH.

---

Pour que cette solution fonctionne, tu supposes que tous les chemins dont tu as besoin sont dans le PATH de chaque utilisateur sur chaque machine cible, ce qui n'est pas forcement le cas.
Et tu supposes egalement que ton script ne sera jamais mis dans une crontab par un utilisateur, ce qui n'est encore une fois pas forcement le cas.

Voila pourquoi j'utilise toujours des chemins absolus, meme si c'est plus contraignant ou plus long a ecrire.

Citation:

---

Envoyé par jack-ft

Pourquoi passes-tu par "echo"??? Y a-t-il une différence avec ceci:

Code:

---

1 2	cd toto res=$?

---

---

Oui : lorsque je tape $? dans mon terminal pour tester (avant de poster donc), ca n'affiche pas la valeur :)

Donc non, pas de difference a ma connaissance.

Je suis plutôt d'accord avec vous tous .

Faire un CD pour lancer un script n'est pas pertinent ...j'ai fini par comprendre pourqoi il utilisait afin d'utiliser des fichiers de config qui était défini également par des chemins relatifs et non absolue j'ai proposé de mettre tous les chemin en absolue plus simple et script que l'on peut lancer de n'importe où .
Beaucoup moins dangereux si répertoire saute d'un admin.
:ccool: