Discussion :

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

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

1
2
3
#!/bin/ksh
 
cd /usr/bin/dev/; /monscript.ksh

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

Code :

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

1
2
3
#!/bin/ksh
 
/usr/bin/dev/monscript.ksh

Pour vous lequel est plus optimisé ou plus efficace ?

Merci pour vos lumières

[frp31]

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

[gangsoleil]

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 :

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

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.

[jojo971]

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

Code :

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

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

[gangsoleil]

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 :

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

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 :

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

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.

[jack-ft]

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)

Code :

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

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

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

Code :

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

1
2
cd toto
res=$?

[jack-ft]

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 :

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

1
2
3
#!/bin/ksh
 
cd /usr/bin/dev/; /monscript.ksh

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

Code :

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

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 :

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

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(

[gangsoleil]

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.