variable PATH dans des scripts

Le
Kevin Denis
Bonjour,

je suis en train de mettre à jour différents scripts afin de les
adapter à différents environnements.

De manière générale (et c'est une question plus large), je vois
souvent des scripts démarrer par une définition des binaires utilisés,
comme par exemple:
#! /bin/sh
LS=/bin/ls
WC=/usr/bin/wc
echo le nombre de fichier est `LS|WC`

Ma première question est la suivante, pourquoi utiliser une définition
littérale alors que l'on peut utiliser PATH?
#! /bin/sh
PATH=/bin:/usr/bin
echo le nombre de fichier est `ls|wc`

Ma seconde question, plus spécifique à mon cas, puisque selon
l'architecture les binaires sont dans des lieux différents:
Mieux vaut il faire
#! /bin/sh
PATH=/opt/bin:/bin etc..

ou bien:
#! /bin/sh
if [ test archi ] then
LS=/bin/ls
else
LS=/opt/bin/ls
fi

etc..

Merci.
--
Kevin
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 10
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #6708151
Kevin Denis wrote in message
je suis en train de mettre à jour différents scripts afin de les
adapter à différents environnements.
<snip>


Pour moi, un script (ou un programme) n'a ni à invoquer une commande externe
par son chemin complet, ni à changer $PATH : la sémantique de $PATH, c'est
précisément d'indiquer où se trouvent les commandes usuelles. Si ce n'est
pas le cas, c'est que la configuration de la machine est cassée à grande
échelle, et c'est ça qu'il faut réparer, il ne faut pas faire cinquante
workarounds crades dans des scripts.

Vincent Lefevre
Le #6708541
Dans l'article Nicolas George
Pour moi, un script (ou un programme) n'a ni à invoquer une commande
externe par son chemin complet, ni à changer $PATH : la sémantique
de $PATH, c'est précisément d'indiquer où se trouvent les commandes
usuelles.


C'est le cas général, mais il y a des exceptions:
* Initialisation: par exemple, dans tout ce qui est lié à cron,
parce qu'on n'hérite pas forcément du bon environnement.
* Sécurité (e.g. dans les scripts Perl setuid, quand ils sont
supportés).
* Wrappers d'applications installées dans tel ou tel répertoire
(e.g. OpenOffice); généralement, on ajoute des répertoires au
$PATH courant.
* Appel d'une commande particulière quand il peut y en avoir
plusieurs installées sur le système et pas toutes compatibles
(c'est ce que fait libtool pour la commande "file": le chemin
/usr/bin/file est hardcodé).

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Nicolas George
Le #6708531
Vincent Lefevre wrote in message
* Initialisation: par exemple, dans tout ce qui est lié à cron,
parce qu'on n'hérite pas forcément du bon environnement.


Celui-ci souligne la faiblesse des shells invoqués de ne pas avoir de
mécanisme pour initialiser l'environnement systématiquement. zsh n'a pas ce
problème.

* Sécurité (e.g. dans les scripts Perl setuid, quand ils sont
supportés).


Ça c'est raisonnable.

* Wrappers d'applications installées dans tel ou tel répertoire
(e.g. OpenOffice); généralement, on ajoute des répertoires au
$PATH courant.


Là, beurk. Ces applications sont mal conçues ou mal installées.

* Appel d'une commande particulière quand il peut y en avoir
plusieurs installées sur le système et pas toutes compatibles
(c'est ce que fait libtool pour la commande "file": le chemin
/usr/bin/file est hardcodé).


Et là, re-beurk. Si on met un répertoire avant un autre dans le PATH, c'est
normalement justement que les versions qui s'y trouvent sont meilleures.

Et en général, je considère plutôt libtool comme exemple de choses à ne pas
faire, donc bon.

Cyrille Lefevre
Le #6708511
Vincent Lefevre wrote in message
[snip]

* Wrappers d'applications installées dans tel ou tel répertoire
(e.g. OpenOffice); généralement, on ajoute des répertoires a u
$PATH courant.


Là, beurk. Ces applications sont mal conçues ou mal installées.


au contraire, les applications propres ne polluent pas le système
en se mettant partout. il me semble normal qu'une application importante
tel qu'OO s'installe qqp dans /opt ou autre avec son bin, son etc, ces
lib, etc. et met à jours les variables dont elle a besoin en fonction d e
ces répertoires. en général, PATH, LD_LIBRARY_PATH ou équivalent, etc.
j'ai bien dit mas et non écrasement, soit PATH=/opt/OO/bin:$PATH, etc .

autre pb, le fait de passer par des wrapper permet de contourner les pbs
de compatibilité des bibliothèques entre 2 appli, les lib ssh par ex.
qui ne sont pas au même niveau. et si ton chemin pointe sur une appli,
l'autre ne marche pas et vice versa.

* Appel d'une commande particulière quand il peut y en avoir
plusieurs installées sur le système et pas toutes compatibles
(c'est ce que fait libtool pour la commande "file": le chemin
/usr/bin/file est hardcodé).


Et là, re-beurk. Si on met un répertoire avant un autre dans le PAT H, c'est
normalement justement que les versions qui s'y trouvent sont meilleures .


ou l'inverse, imagine un script écrit pour du sunos pur avec
/usr/xpg4/bin en premier. dans ce cas, il peut être interressant qu'il y
ait un PATH=/usr/bin:/usr/ucb:$PATH au début pour être sur qu'il
fonctionne tel qu'attendu.

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.


Cyrille Lefevre
Le #6708501
Kevin Denis wrote in message
je suis en train de mettre à jour différents scripts afin de les
adapter à différents environnements.
<snip>


Pour moi, un script (ou un programme) n'a ni à invoquer une commande externe
par son chemin complet, ni à changer $PATH : la sémantique de $PATH , c'est
précisément d'indiquer où se trouvent les commandes usuelles. Si ce n'est
pas le cas, c'est que la configuration de la machine est cassée à g rande
échelle, et c'est ça qu'il faut réparer, il ne faut pas faire cin quante
workarounds crades dans des scripts.


pas nécessairement, en prod tu as souvent des conflit d'une appli avec
une autre et le chemin système ne suffit pas, au contraire, il faut
souvent le contourner. plus précisément, le fait de forcer le PATH te
permet d'être sur du comportement de ton script qqsoit son environnemen t
d'exécution, surtout s'il y a des GNUeserie dans le coin :)

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.


Alain Montfranc
Le #6708991
Nicolas George a écrit
Kevin Denis wrote in message
je suis en train de mettre à jour différents scripts afin de les
adapter à différents environnements.
<snip>


Pour moi, un script (ou un programme) n'a ni à invoquer une commande externe
par son chemin complet, ni à changer $PATH : la sémantique de $PATH, c'est
précisément d'indiquer où se trouvent les commandes usuelles. Si ce n'est
pas le cas, c'est que la configuration de la machine est cassée à grande
échelle, et c'est ça qu'il faut réparer, il ne faut pas faire cinquante
workarounds crades dans des scripts.


Vous n'avez jamais fait de scipts pour cron ?


Kevin Denis
Le #6708981
On 2008-05-26, Cyrille Lefevre wrote:
je suis en train de mettre à jour différents scripts afin de les
adapter à différents environnements.


Pour moi, un script (ou un programme) n'a ni à invoquer une commande externe
par son chemin complet, ni à changer $PATH : la sémantique de $PATH, c'est
précisément d'indiquer où se trouvent les commandes usuelles. Si ce n'est
pas le cas, c'est que la configuration de la machine est cassée à grande
échelle, et c'est ça qu'il faut réparer, il ne faut pas faire cinquante
workarounds crades dans des scripts.


pas nécessairement, en prod tu as souvent des conflit d'une appli avec
une autre et le chemin système ne suffit pas, au contraire, il faut
souvent le contourner. plus précisément, le fait de forcer le PATH te
permet d'être sur du comportement de ton script qqsoit son environnement
d'exécution, surtout s'il y a des GNUeserie dans le coin :)

Bah voilà.

Mais je me trouve face a plusieurs scripts qui prennent le soin de
définir chacun des chemins menant au binaire (50% dans le PATH, 50%
sont des binaires métiers rangés dans différents répertoires selon
la version).

Les scripts démarrent par une litanie de définitions, alors que
je me verrais plutôt faire un:
PATH=/bin:/usr/bin:/opt/v5/bin:/usr/v4/bin
et la, je suis sur d'appeler le bon binaire, au lieu de devoir
redéfinir selon le chemin, etc..
Je peux affiner si besoin est avec un
if [ version=5 ] then
PATH=...
else
PATH=...
fi

Mais le fait que je voie énormément de script appeler chaque
binaire par leur chemin me fait douter de ma méthode.

En forçant un PATH en début de script au lieu de définir le chemin
complet de chaque binaire, est ce que je risque un problème? Lequel?
--
Kevin



Vincent Lefevre
Le #6708971
Dans l'article Nicolas George
Vincent Lefevre wrote in message
* Initialisation: par exemple, dans tout ce qui est lié à cron,
parce qu'on n'hérite pas forcément du bon environnement.


Celui-ci souligne la faiblesse des shells invoqués de ne pas avoir
de mécanisme pour initialiser l'environnement systématiquement. zsh
n'a pas ce problème.


On peut vouloir un environnement plus limité pour les scripts
exécutés via cron que pour l'environnement en interactif. Par
exemple, pour les scripts exécutés via cron, on n'inclut que
des répertoires locaux afin de ne pas perturber le système en
cas de problème avec NFS.

* Wrappers d'applications installées dans tel ou tel répertoire
(e.g. OpenOffice); généralement, on ajoute des répertoires au
$PATH courant.


Là, beurk. Ces applications sont mal conçues ou mal installées.


Au contraire. Par exemple, dans le répertoire privé d'OpenOffice, tu
as tout un tas de programmes utilisés en interne qu'on ne voudrait
pas voir normalement dans son $PATH: cela évite des conflits de noms
(même si "open-url" pourrait être nommé "openoffice-open-url" pour
éviter de tels conflits) et cela évite qu'ils se retrouvent dans la
liste des exécutables dispo via $PATH (cela perturbe ainsi moins la
complétion sur les exécutables, donne un hash moins gros, évite que
l'utilisateur les exécute par erreur...).

* Appel d'une commande particulière quand il peut y en avoir
plusieurs installées sur le système et pas toutes compatibles
(c'est ce que fait libtool pour la commande "file": le chemin
/usr/bin/file est hardcodé).


Et là, re-beurk. Si on met un répertoire avant un autre dans le
PATH, c'est normalement justement que les versions qui s'y trouvent
sont meilleures.


Ce n'est pas une question d'être meilleur, c'est une question de
compatibilité. Par exemple, le "file" du vendeur peut fournir une
sortie différente de celui d'un "file" installé par l'utilisateur
(e.g. le "file" classique). Même genre de choses pour des
utilitaires dont on cherche à utiliser des options non standard
(mais dont on sait qu'elles sont disponibles avec l'utilitaire du
vendeur). Par exemple, j'ai tendance à préférer GNU sed si bien
qu'il est en premier dans mon $PATH, mais certains scripts pour
Mac OS X peuvent préférer utiliser le sed du système (BSD), qui
a une option non standard -E non disponible dans GNU sed.

Les développeurs de libtool mentionnent aussi une question de
rapidité, mais je doute qu'il y ait une différence pratique ici
compte tenu de tout ce que fait libtool par ailleurs.

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


Nicolas George
Le #6708961
Cyrille Lefevre wrote in message
au contraire, les applications propres ne polluent pas le système
en se mettant partout.


Ce n'est pas la manière Unix de procéder.

autre pb, le fait de passer par des wrapper permet de contourner les pbs
de compatibilité des bibliothèques entre 2 appli, les lib ssh par ex.


Il y a les SONAME, pour ça. Et de toutes façons ce n'est pas $PATH qui règle
ça.

Nicolas George
Le #6708951
Cyrille Lefevre wrote in message
pas nécessairement, en prod tu as souvent des conflit d'une appli avec
une autre et le chemin système ne suffit pas, au contraire, il faut
souvent le contourner.


Exemple concret ?

Publicité
Poster une réponse
Anonyme