extraire le chemin d'un script

Version imprimable

08/06/2010, 13h21
d10g3n

extraire le chemin d'un script

Bonjour,

pour charger un fichier de config d'un script (contenant les différentes constantes à initialiser), je suis obligé de sourcer le fichier avec son chemin exact :

Code:

source /chemin_du_script/monfichier.ini

j'aimerais pouvoir rendre le chargement de ce fichier de config indépendant de sa localisation. J'avais imaginer faire quelque chose du type :

Code:

$(pwd)/monfichier.ini

or, pwd me renvoie le chemin depuis lequel on exécute le script, pas celui où se trouve le script.

Comment faire ?
08/06/2010, 14h24
N_BaH

le palais des glaces...

vois ceci...
?
08/06/2010, 14h54
d10g3n

merci beaucoup, désolé de ne pas avoir cherché comme il faut sur le forum...
la solution est donc :

Code:

execPath=$(cd (dirname $0); pwd)
08/06/2010, 15h02
d10g3n

en fait :

Code:

execPath=$(dirname $0)

suffit largement...
11/06/2010, 17h20
AnsuzPeorth

Citation:

Envoyé par d10g3n

en fait :

Code:

execPath=$(dirname $0)

suffit largement...

Non, dans certain cas, cela ne sera pas suffisant .(chemin relatif, absolu)
De plus, aucune des solutions ne protègent des espaces dans le path

Si des personnes chevronnées te dirigent vers un post, c'est que c'est LA solution, et tu penses bien que TA solution, ils la connnaissent, si ils ne l'indiquent pas, c'est pas pour rien ;)

PS: perso, j'écris comme ça, je double les cotes pour protéger des espaces, et je ne savais pas qu'on pouvait se passer du $ pour le dirname ! (a moins que le $ oblige la protection des blancs)

Code:

path=$(cd "$(dirname "$0")"; pwd)
12/06/2010, 11h26
Drawingrom
en bash on a aussi

path="$(cd "${0%/*}"; pwd)"

il faut pas oublier les guillemets dans ta définition de variable :D.
Utiliser des espace dans les chemins unix, il faut être joueur...

exemple (remplace var par 0):
Code:

1 2 3 4 5 romain@lilibox:~$ var="un machin/truc" romain@lilibox:~$ toto="$(cd "${var%/*}"; pwd)" romain@lilibox:~$ echo $toto /home/romain/un machin
14/06/2010, 22h18
Sve@r

Citation:

Envoyé par AnsuzPeorth

Non, dans certain cas, cela ne sera pas suffisant .(chemin relatif, absolu)

Hum, dans 99,9% des cas, si on cherche le chemin du script, c'est parce qu'on a besoin d'aller chercher un fichier particulier et qu'on sait où est ce fichier par rapport au script.
Et donc dans ces 99,9% des cas, qu'on récupère le chemin relatif ou absolu ne changera rien car on saura, à partir de ce chemin récupéré, trouver le fichier qui nous intéresse.
En l'occurrence, d10g3n a juste besoin de récupérer un fichier "monfichier.ini" situé dans le même répertoire que le script, ici la solution path=$(dirname $0) suffira amplement et fonctionnera qu'on ait lancé le script en relatif ou en absolu...

Citation:

Envoyé par AnsuzPeorth

PS: perso, j'écris comme ça, je double les cotes pour protéger des espaces, et je ne savais pas qu'on pouvait se passer du $ pour le dirname ! (a moins que le $ oblige la protection des blancs)

Code:

path=$(cd "$(dirname "$0")"; pwd)

Non. Le $(...) symbolise l'appel à une commande et il est obligatoire. Ou alors on passe par l'ancienne syntaxe `...`
14/06/2010, 23h51
AnsuzPeorth

Citation:

Hum, dans 99,9% des cas

J'ai pas eu de bol alors, j'ai déjà été confronté aux 0.1% (et pour le trouver, qd ca arrive....merci !)
Si je me souviens bien, j'avais lancé le script depuis un support usb.
Donc, depuis, je sécurise, ça mange pas de pain :)
17/06/2010, 19h24
Sve@r

Citation:

Envoyé par AnsuzPeorth

J'ai pas eu de bol alors, j'ai déjà été confronté aux 0.1% (et pour le trouver, qd ca arrive....merci !)
Si je me souviens bien, j'avais lancé le script depuis un support usb.
Donc, depuis, je sécurise, ça mange pas de pain :)

Mouais. J'arrive pas trop à imaginer un cas où $(dirname $0) ne suffit pas. J'ai écrit 99,9% parce que la certitude absolue n'existe pas mais je pensais quand-même que ça valait 100%.
Si encore t'étais sous zindow, ça pourrait peut-être s'expliquer (avec les C:\ ou F:\ ou ...). Mais un support USB, une fois monté, est vu comme n'importe quel chemin Unix.

Ca semble maintenant fort vieux et j'étais pas présent donc je peux pas affirmer grand chose. Mais je pense quand-même qu'il pourrait s'agir d'un problème "autre" qui a eu un effet de bord sur le chemin récupéré.

Ton histoire me fait penser à une autre situation qui y ressemble : j'ai parfois des élèves en shell (car je donne des cours de temps en temps) qui se ramassent sur la commande test et qui écrivent test $truc=$machin (sans espace entre le "="). Comme la commande hurle, ils trouvent rien de mieux à faire que de "sécuriser" en mettant test $truc=$machin 2>/dev/null. Là non plus ça ne mange pas de pain :aie:

Bon, c'était juste pour faire partager mon impression. Encore une fois, tu as eu probablement raison ce jour là mais faut quand-même penser que s'il y a une erreur, il vaut mieux parfois chercher le pourquoi de l'erreur plutôt que partir dans une autre direction...
17/06/2010, 23h02
AnsuzPeorth

Bjr,
Ce me chagrinais c't'affaire ... J'ai recherché qd j'avais eu ce problème, ca remonte à plus d'un an, c'est pour ça que c'était plus très clair (j'ai dormis depuis :))

Alors, c'est vrai que le problème que j'avais rencontré n'est pas le même que celui soulevé ici.

Pour un script, je créais un lanceur, il me fallait le chemin absolu de l'executable.

Code:

path=$(dirname $0)

Si on lançait le script en double-clic (console ou pas), pas de problèmes, le path était bien le chemin absolu. Par contre, si on lançait depuis la console (./script.sh), c'est le chemin relatif qu'on obtenait, donc il m'a fallu utiliser l'autre commande qui me donnait le chemin absolu peut importe le lancement.
C'est donc pas vraiment indiqué pour le problème de ce fil. Désolé !

Citation:

Là non plus ça ne mange pas de pain

Merci pour la comparaison ...Ca a le mérite d'être clair au moi :mrgreen: