Récupérer le répertoire du script en cours d'exécution

Bonjour,

Je suis en train de faire un script qui doit savoir où il est, car il va travailler sur des fichiers dont il connait la position par rapport à lui même.

J'ai trouvé de nombreuses solutions sur le web, mais aucune ne m'a satisfaite.

• pwd/$PWD -> C'est le répertoire courant, pas le répertoire du script.
  
• which -> Ne trouve pas la commande lors d'un appel de ce type là :
  Code:

  ---

  ./rep/foo.sh

  ---

  si /rep n'est pas dans le path.
  
• $0 -> Ne fonctionne pas si on fait :
  Code:

  ---

  . ./foo.sh

  ---

  ou
  Code:

  ---

  bash foo.sh

  ---

• $BASH_SOURCE -> Idéal s'il n'était pas dispo uniquement sous bash version 3.0 mini. Il me faudrait plutôt un code pour bash 2.0.3 mini.

Donc si vous avez d'autres solutions, merci d'avance.

Passé il y a quelques jours :

http://www.developpez.net/forums/d82...ipt-execution/

:ccool:

edit: et le lien direct vers la solution :
http://www.developpez.net/forums/d79...r/#post4586928

Et pour bien te former voir les Cours et tutoriels pour bien apprendre Scilab : http://scilab.developpez.com/cours/

Merci pour cette réponse rapide !

Mais cela ne me convient pas. readlink a besoin de deviner de quel fichier on parle. Si le script est lancé depuis un autre répertoire avec un chemin relatif (rep/script.sh), le fichier n'est pas trouvé. La solution qui vient à l'esprit est alors readlink $0. Mais comme précisé dans ma question, $0 n'est pas toujours utilisable.

Citation:

---

Envoyé par rt15

Bonjour,

Je suis en train de faire un script qui doit savoir où il est, car il va travailler sur des fichiers dont il connait la position par rapport à lui même.

J'ai trouvé de nombreuses solutions sur le web, mais aucune ne m'a satisfaite.

• pwd/$PWD -> C'est le répertoire courant, pas le répertoire du script.
  
• which -> Ne trouve pas la commande lors d'un appel de ce type là :
  Code:

  ---

  ./rep/foo.sh

  ---

  si /rep n'est pas dans le path.
  
• $0 -> Ne fonctionne pas si on fait :
  Code:

  ---

  . ./foo.sh

  ---

  ou
  Code:

  ---

  bash foo.sh

  ---

• $BASH_SOURCE -> Idéal s'il n'était pas dispo uniquement sous bash version 3.0 mini. Il me faudrait plutôt un code pour bash 2.0.3 mini.

Donc si vous avez d'autres solutions, merci d'avance.

---

Code:

---

1 2	dirname $PWD/$0

---

ne convient pas ?

(ce ne sera évidemment pas un path canonisé… )

Bien tenté, mais non plus.:aie:

Classiquement ça marche très bien, mais le souci est qu'on appelle nos scripts de manière à ce qu'ils s'exécutent dans le shell courant, comme les scripts "configure" :

Code:

---

. ./configure

---

Et dans ces cas là, $0, c'est "bash", donc inutilisable...:?

[ edit ]
Je dois aussi supporter le cas suivant :

Code:

---

. ./UnRep/configure

---

Ce cas n'est pas géré sur le ./configure dans lequel j'ai jeté un oeil :
bash: error: cannot find sources (src/version.c) in . or ..

Citation:

---

Envoyé par rt15

Bien tenté, mais non plus.:aie:

Classiquement ça marche très bien, mais le souci est qu'on appelle nos scripts de manière à ce qu'ils s'exécutent dans le shell courant, comme les scripts "configure" :

Code:

---

. ./configure

---

Et dans ces cas là, $0, c'est "bash", donc inutilisable...:?

---

oui c'est le seul cas qui ne fonctionne pas tel quel…
mais on peut le détecter car dans le fichier sourcé le $BASH_ARGV contient le nom du programme alors qu'il est vide dans les autres cas…

Code:

---

1 2 3 4 5 6 7

if [ "$BASH_ARGV" == "" ] then path=$PWD/$0 else path=$PWD/$BASH_ARGV fi

---

Merci encore, mais ce n'est pas encore ok... Mais y a de l'idée !:ccool:

Le problème étant que BASH_ARGV n'est pas inclus dans les vielles versions de bash (2.0.3, 2.0.5...). Y aurait pas une autre variable qui donne plus ou moins la même chose ?

Citation:

---

Envoyé par rt15

Merci encore, mais ce n'est pas encore ok... Mais y a de l'idée !:ccool:

Le problème étant que BASH_ARGV n'est pas inclus dans les vielles versions de bash (2.0.3, 2.0.5...). Y aurait pas une autre variable qui donne plus ou moins la même chose ?

---

accédez à un de ces anciens bash et mettez une ligne

Code:

---

1 2

set

---

au début d'un script … et comparez le résultat entre les exécutions "sourcée" et "normale" …

Arf... Il y a beaucoup de différences, mais ce qui est sûr c'est qu'aucune variable ne contient un équivalent de $0 ou de BASH_ARGV... Donc même si j'arrivais à faire la différence entre les modes, je ne pourrais pas déterminer le bon chemin.

Code:

---

1 2 3 4 5 6

if [ Un truc pas très propre ] then path=$PWD/$0 else path=$PWD/?????????? fi

---

il ne vous reste plus qu'à imposer une variable d'environnement contenant le path en question pour les bash pre-BASH_ARGV…

si aucune des deux variables n'est définie… vous sortez avec un message d'erreur…

Bin c'est à peu près ce qu'on fait à l'heure actuelle : faut setter une XXXX_HOME avant de lancer le script. Mais je voulais m'en passer car c'est assez fastidieux (Et cependant trop changeant pour un mettre une valeur en dur dans un .bashrc ou autre), mais visiblement ce n'est pas possible sur nos vieux serveurs...:calim2:

En tout cas merci d'avoir consacré ton temps à ma question.:zoubi:

Je veux pas être méchant, mais je pense qu'il faudrait revoir l'algo ;)

Le problème dans ton exemple, c'est la possibilité de lancer le script avec "."

Je ne connais pas en détail le fonctionnement du bash, mais pour moi, si tu fais . test/test.bash, ben tu n'as aucun moyen de savoir d'où est lancé ton script, puisqu'il n'est justement pas vraiment lancé... mais plutôt interprété au fur et à mesure... donc c'est mort.

Je pense que tous les autres cas peuvent être traité, mais pas source (que je n'avais pas vu au début) !

Toutefois, cette phrase m'interpelle:

Citation:

---

car il va travailler sur des fichiers dont il connait la position par rapport à lui même

---

Si il connait la position par rapport à lui même, il n'a donc justement pas besoin de savoir où il est puisque les positions deviennent absolues par rapport à sa propre position ?!

Citation:

---

Envoyé par Alek-C

Je veux pas être méchant, mais je pense qu'il faudrait revoir l'algo ;)

---

Bin globalement, je cherche à faire un script "configure" classique qui met en place l'environnement pour que l'on puisse ensuite taper un certain nombre de commandes qui vont exploiter cet environnement. Sauf que d'habitude, ce genre de script est exécuté alors qu'il est dans le répertoire courant :

Code:

---

. ./configure

---

Alors que le mien devrait pouvoir être exécuté depuis n'importe quel répertoire, genre :

Code:

---

. ./UnOuDeuxRepToutAFaitAléatoires/configure

---

Code:

---

Si il connait la position par rapport à lui même, il n'a donc justement pas besoin de savoir où il est puisque les positions deviennent absolues par rapport à sa propre position ?!

---

Le souci c'est que les fichiers sont cherchés à partir du répertoire courant, et pas celui du script. Donc même si le script "sait" qu'il y a toto.sh dans le même répertoire que lui, il ne peut cependant pas l'exécuter en faisant simplement toto.sh.

Voilà un script fic1 qui appelle un script fic2 qui affiche blah.

Code:

---

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

>mkdir subdir >cd subdir/ >echo "fic2.sh" > fic1.sh >echo "echo blah" > fic2.sh >chmod a+rx * >. ./fic1.sh blah >cd .. >. ./subdir/fic2.sh blah >. ./subdir/fic1.sh bash: fic2.sh: command not found >

---

Ci-dessus, fic2.sh est cherché dans le répertoire courant, pas dans le répertoire de fic1.sh. On est obligé d'appeler fic1 en se plaçant dans son répertoire pour que cela fonctionne.

Le problème ici, c'est que tu source tes scripts, si :

Code:

---

1 2 3 4 5 6 7

$ cd subdir $ echo "./$(dirname $0)/fic2.sh" > fic1.sh $ ./fic1.sh blah $ cd .. $ ./subdir/fic1.sh blah

---

...
?

Tu peux sourcer fic2.sh depuis fic1.sh, mais pas fic1.sh depuis le shell.

D'ailleurs, si :

Code:

---

1 2 3 4 5

$ echo -e ". ./$(dirname $0)/fic2.sh\necho $var" > subdir/fic1.sh $ echo -e "var=blabla\necho blah" > subdir/fic2.sh $ subdir/fic1.sh blah blabla

---

Cependant je suis bien obligé de sourcer, vu que mon script est un genre de .bashrc.

Citation:

---

Envoyé par rt15

Cependant je suis bien obligé de sourcer, vu que mon script est un genre de .bashrc.

---

l'habitude avec les produits OpenSource, c'est de faire

Code:

---

1 2 3

./configure [options] make [install]

---

le tout exécuté toujours à partir du répertoire d'installation et de nulle part ailleurs…

est-ce que vous ne vous compliquez pas inutilement la tâche en vous posant des contraintes qui n'ont pas lieu d'être ?

Ca ressemble au paradoxe de la poule et de l'oeuf ....

Citation:

---

Envoyé par JeitEmgie

est-ce que vous ne vous compliquez pas inutilement la tâche en vous posant des contraintes qui n'ont pas lieu d'être ?

---

L'objectif était de se compliquer la tâche une bonne fois pour toute maintenant de manière à la simplifier plus tard (ie, ne pas avoir à se déplacer dans le répertoire qui va bien pour le restant de nos jours).

D'autre part, sur le plan théorique, être en mesure de faire "un script qui devine son propre emplacement en toute circonstance", ça me paraît pas déconnant dans tout un tas de cas...

Citation:

---

Envoyé par rt15

L'objectif était de se compliquer la tâche une bonne fois pour toute maintenant de manière à la simplifier plus tard (ie, ne pas avoir à se déplacer dans le répertoire qui va bien pour le restant de nos jours).

D'autre part, sur le plan théorique, être en mesure de faire "un script qui devine son propre emplacement en toute circonstance", ça me paraît pas déconnant dans tout un tas de cas...

---

certes…
mais ce qui est une contrainte inutile c'est de vouloir couvrir le cas du "sourcing" du script :

Code:

---

1 2	. ./configure

---

car cette façon de faire est contraire aux habitudes… et c'est ce seul cas qui pose problème…

on exécute toujours le script principal de configuration … et lui, éventuellement, "source" des scripts de paramètres…

Bonjour à tous,

De mon côté, j'ai voulu créer un menu pouvant être lancé de manières suivantes :
menu
./menu
/chemin/menu
. menu


Pour arriver à mes fins, j'ai dû créer un script faisant office de lanceur du script principal et devant être présent dans la varaible PATH :

/chemin/menu
exit

Ceci me permet (dans les 3 premiers cas) de lancer le menu et de revenir sur la ligne de commande après l'avoir quitté.
Le quatrième cas empêche d'avoir la ligne de commande, exit me déconnecte totalement de la machine, en le plaçant dans le ". profile" et en bloquant les interruptions, cela empêche totalement certains utilisateurs d'avoir accès à la ligne de commande.

Essaie de coupler les 2 idées : la commande pwd pour la recherche de fichiers et le lanceur de scripts.

As-tu pensé aux alias ?

Citation:

---

Envoyé par JeitEmgie

certes…
mais ce qui est une contrainte inutile c'est de vouloir couvrir le cas du "sourcing" du script :

Code:

---

1 2	. ./configure

---

car cette façon de faire est contraire aux habitudes… et c'est ce seul cas qui pose problème…

on exécute toujours le script principal de configuration … et lui, éventuellement, "source" des scripts de paramètres…

---

+1 : exécuter un script de n'importe où ne pose pas de souci, sourcer un fichier de n'importe où oui, et on ne lance pas un configure avec un . ./configure mais bien un ./configure !

Certes, nous n'avons pas fait comme tout le monde... :? Notre "configure" ne génère pas de Makefile, il ne fait que setter des variables d'environnement, d'où la nécessité de sourcer. Sa finalité n'est pas la même d'ailleurs, on ne le livre pas : il ne sert qu'à mettre en place l'environnement de travail des développeurs.

En y repensant, on devrait d'ailleurs pouvoir s'en passer de ce script, comme on a fait sur d'autre projets.

En tout cas, merci tout le monde. :)
Je marque le topic en résolu.