Discussion :

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

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

  ./rep/foo.sh

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

  Code :

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

  . ./foo.sh

  ou

  Code :

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

  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.

[lennelei]

Passé il y a quelques jours :

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



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/

[rt15]

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.

[JeitEmgie]

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 :

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

  ./rep/foo.sh

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

  Code :

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

  . ./foo.sh

  ou

  Code :

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

  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 :

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

1
2
 
dirname $PWD/$0

ne convient pas ?

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

[rt15]

Bien tenté, mais non plus.

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 :

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

. ./configure

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

[ edit ]
Je dois aussi supporter le cas suivant :

Code :

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

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

[JeitEmgie]

Bien tenté, mais non plus.

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 :

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

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

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

1
2
3
4
5
6
7
 
if [ "$BASH_ARGV" == "" ]
then
	path=$PWD/$0
else
	path=$PWD/$BASH_ARGV
fi

[rt15]

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

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 ?

[JeitEmgie]

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

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 :

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

1
2
 
set

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

[rt15]

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 :

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

1
2
3
4
5
6
if [ Un truc pas très propre ]
then
	path=$PWD/$0
else
	path=$PWD/??????????
fi

[JeitEmgie]

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…

[rt15]

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

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

[lennelei]

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:

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

[rt15]

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 :

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

. ./configure

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

Code :

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

. ./UnOuDeuxRepToutAFaitAléatoires/configure

Code :

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

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 :

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

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.

[N_BaH]

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

Code :

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

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 :

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

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

[rt15]

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

[JeitEmgie]

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 :

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

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 ?

[noooop]

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

[rt15]

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

[JeitEmgie]

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 :

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

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…

[syjis]

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 ?