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
Vincent Lefevre wrote in message <20080526102936$:
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).
La version installée par l'administrateur peut reconnaître plus fiablement les types des fichiers.
On parle d'Unix, là, pas de windows : l'administrateur est réputé savoir ce qu'il fait.
Vincent Lefevre wrote in message
<20080526102936$62a2@prunille.vinc17.org>:
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).
La version installée par l'administrateur peut reconnaître plus fiablement
les types des fichiers.
On parle d'Unix, là, pas de windows : l'administrateur est réputé savoir ce
qu'il fait.
Vincent Lefevre wrote in message <20080526102936$:
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).
La version installée par l'administrateur peut reconnaître plus fiablement les types des fichiers.
On parle d'Unix, là, pas de windows : l'administrateur est réputé savoir ce qu'il fait.
Nicolas George
Alain Montfranc wrote in message :
Vous n'avez jamais fait de scipts pour cron ?
Avec un shell qui initialise l'environnement.
Alain Montfranc wrote in message <mn.d2f17d851bb47cd3.51095@x.con>:
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
Pour des scripts que tu écris toi-même et qui ne tourneront que sur ta machine, c'est peut-être acceptable. Pour un script fourni par un développeur d'une application qui devra tourner sur une multitude de plateformes différentes, il en est tout autrement, et en général, il suffit juste d'ajouter des répertoires en tête du $PATH. Mais ça peut être plus compliqué si le script cherche à utiliser des ressources fournies par le système (bibliothèques, Java, etc.) qui ne sont pas forcément disponibles sans rien faire.
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?
Dans certains cas, utiliser le chemin complet (une fois déterminé au début) peut être plus rapide. C'est ce que font les autotools, car certains utilitaires sont exécutés très souvent. En effet, si un utilitaire se situe loin dans le $PATH, ça peut prendre du temps au shell de le rechercher à chaque fois, surtout s'il y a du NFS. Certains shells ont un système de cache, mais pas tous (d'autant plus que le système de cache a ses inconvénients).
Dans l'article <slrng3l1tu.4f2.kevin@slackwall.local.tux>,
Kevin Denis <kevin@nowhere.invalid> écrit:
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
Pour des scripts que tu écris toi-même et qui ne tourneront que sur
ta machine, c'est peut-être acceptable. Pour un script fourni par un
développeur d'une application qui devra tourner sur une multitude de
plateformes différentes, il en est tout autrement, et en général, il
suffit juste d'ajouter des répertoires en tête du $PATH. Mais ça peut
être plus compliqué si le script cherche à utiliser des ressources
fournies par le système (bibliothèques, Java, etc.) qui ne sont pas
forcément disponibles sans rien faire.
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?
Dans certains cas, utiliser le chemin complet (une fois déterminé
au début) peut être plus rapide. C'est ce que font les autotools,
car certains utilitaires sont exécutés très souvent. En effet, si
un utilitaire se situe loin dans le $PATH, ça peut prendre du temps
au shell de le rechercher à chaque fois, surtout s'il y a du NFS.
Certains shells ont un système de cache, mais pas tous (d'autant
plus que le système de cache a ses inconvénients).
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
Pour des scripts que tu écris toi-même et qui ne tourneront que sur ta machine, c'est peut-être acceptable. Pour un script fourni par un développeur d'une application qui devra tourner sur une multitude de plateformes différentes, il en est tout autrement, et en général, il suffit juste d'ajouter des répertoires en tête du $PATH. Mais ça peut être plus compliqué si le script cherche à utiliser des ressources fournies par le système (bibliothèques, Java, etc.) qui ne sont pas forcément disponibles sans rien faire.
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?
Dans certains cas, utiliser le chemin complet (une fois déterminé au début) peut être plus rapide. C'est ce que font les autotools, car certains utilitaires sont exécutés très souvent. En effet, si un utilitaire se situe loin dans le $PATH, ça peut prendre du temps au shell de le rechercher à chaque fois, surtout s'il y a du NFS. Certains shells ont un système de cache, mais pas tous (d'autant plus que le système de cache a ses inconvénients).
Dans l'article <483a98f0$0$15523$, Nicolas George <nicolas$ écrit:
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.
Il n'y a pas de manière Unix de procéder. Il y a juste des problèmes à résoudre. Et puis Unix a évolué. Ce qui se faisait dans le temps n'est pas forcément bon de nos jours.
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.
Ce n'est pas suffisant. Par exemple, il y a des bibliothèques qui ont le même nom, mais qui sont incompatibles (je pense à readline, en particulier). Certaines bibliothèques peuvent aussi être patchées pour pouvoir fonctionner avec l'application en question. Il y a aussi le problème de pouvoir installer et utiliser plusieurs versions (dont des versions de développement) d'une application; si les applications n'ont pas leur répertoire privé, cela donne des conflits.
Dans l'article <483a98f0$0$15523$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Cyrille Lefevre wrote in message
<483A8BD2.9090604@laposte.net.invalid>:
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.
Il n'y a pas de manière Unix de procéder. Il y a juste des problèmes
à résoudre. Et puis Unix a évolué. Ce qui se faisait dans le temps
n'est pas forcément bon de nos jours.
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.
Ce n'est pas suffisant. Par exemple, il y a des bibliothèques qui
ont le même nom, mais qui sont incompatibles (je pense à readline,
en particulier). Certaines bibliothèques peuvent aussi être
patchées pour pouvoir fonctionner avec l'application en question.
Il y a aussi le problème de pouvoir installer et utiliser plusieurs
versions (dont des versions de développement) d'une application;
si les applications n'ont pas leur répertoire privé, cela donne
des conflits.
Dans l'article <483a98f0$0$15523$, Nicolas George <nicolas$ écrit:
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.
Il n'y a pas de manière Unix de procéder. Il y a juste des problèmes à résoudre. Et puis Unix a évolué. Ce qui se faisait dans le temps n'est pas forcément bon de nos jours.
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.
Ce n'est pas suffisant. Par exemple, il y a des bibliothèques qui ont le même nom, mais qui sont incompatibles (je pense à readline, en particulier). Certaines bibliothèques peuvent aussi être patchées pour pouvoir fonctionner avec l'application en question. Il y a aussi le problème de pouvoir installer et utiliser plusieurs versions (dont des versions de développement) d'une application; si les applications n'ont pas leur répertoire privé, cela donne des conflits.
Vincent Lefevre wrote in message <20080526111452$:
Par exemple, il y a des bibliothèques qui ont le même nom, mais qui sont incompatibles
Ce n'est absolument pas normal. Ton système est cassé.
Vincent Lefevre
Dans l'article <483a99bf$0$15523$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080526102936$:
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).
La version installée par l'administrateur peut reconnaître plus fiablement les types des fichiers.
Attention, libtool est lancé par l'utilisateur qui compile, donc pas forcément par un "administrateur". Concernant "file", le problème est que libtool doit parser la sortie, et pour qu'il puisse la reconnaître, il doit s'assurer d'exécuter un "file" connu.
Note: "file" est avant tout une commande utilisateur, pas une commande système. On ne peut donc pas reprocher à l'utilisateur (ou même administrateur) d'avoir installé une version qu'il juge meilleure (c'est complètement subjectif) dans son $HOME ou dans /usr/local/bin.
Dans l'article <483a99bf$0$15523$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080526102936$62a2@prunille.vinc17.org>:
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).
La version installée par l'administrateur peut reconnaître plus
fiablement les types des fichiers.
Attention, libtool est lancé par l'utilisateur qui compile, donc
pas forcément par un "administrateur". Concernant "file", le
problème est que libtool doit parser la sortie, et pour qu'il
puisse la reconnaître, il doit s'assurer d'exécuter un "file"
connu.
Note: "file" est avant tout une commande utilisateur, pas une
commande système. On ne peut donc pas reprocher à l'utilisateur
(ou même administrateur) d'avoir installé une version qu'il juge
meilleure (c'est complètement subjectif) dans son $HOME ou dans
/usr/local/bin.
Dans l'article <483a99bf$0$15523$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080526102936$:
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).
La version installée par l'administrateur peut reconnaître plus fiablement les types des fichiers.
Attention, libtool est lancé par l'utilisateur qui compile, donc pas forcément par un "administrateur". Concernant "file", le problème est que libtool doit parser la sortie, et pour qu'il puisse la reconnaître, il doit s'assurer d'exécuter un "file" connu.
Note: "file" est avant tout une commande utilisateur, pas une commande système. On ne peut donc pas reprocher à l'utilisateur (ou même administrateur) d'avoir installé une version qu'il juge meilleure (c'est complètement subjectif) dans son $HOME ou dans /usr/local/bin.
Dans l'article <483a9e77$0$31953$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080526111452$:
Par exemple, il y a des bibliothèques qui ont le même nom, mais qui sont incompatibles
Ce n'est absolument pas normal. Ton système est cassé.
Non. Mac OS X fournit un readline BSD (/usr/lib/libreadline.dylib), mais l'utilisateur peut préférer le readline GNU (au passage, sous GPL, pas LGPL, donc pas utilisable avec toutes les applications), par exemple installé via MacPorts: /opt/local/lib/libreadline.dylib
Dans l'article <483a9e77$0$31953$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080526111452$2ec7@prunille.vinc17.org>:
Par exemple, il y a des bibliothèques qui
ont le même nom, mais qui sont incompatibles
Ce n'est absolument pas normal. Ton système est cassé.
Non. Mac OS X fournit un readline BSD (/usr/lib/libreadline.dylib),
mais l'utilisateur peut préférer le readline GNU (au passage, sous
GPL, pas LGPL, donc pas utilisable avec toutes les applications),
par exemple installé via MacPorts: /opt/local/lib/libreadline.dylib
Dans l'article <483a9e77$0$31953$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080526111452$:
Par exemple, il y a des bibliothèques qui ont le même nom, mais qui sont incompatibles
Ce n'est absolument pas normal. Ton système est cassé.
Non. Mac OS X fournit un readline BSD (/usr/lib/libreadline.dylib), mais l'utilisateur peut préférer le readline GNU (au passage, sous GPL, pas LGPL, donc pas utilisable avec toutes les applications), par exemple installé via MacPorts: /opt/local/lib/libreadline.dylib
Vincent Lefevre wrote in message <20080526113449$:
Non.
Si.
Même nom, deux bibliothèques incompatibles.
Je maintiens : si elles sont incompatibles, qu'elles aient le même nom est un bug, il n'y a pas d'autre nom.
Que macos x le fasse n'est absolument pas une preuve.
Nicolas George
Vincent Lefevre wrote in message <20080526113210$:
Il n'y a pas forcément un environnement unique qui convienne à tout le monde.
Il y a presque toujours un environnement qui convienne à la plupart des scripts lancés sur une machine. Que cet environnement soit dupliqué dans chacun des scripts est totalement contre-productif et crétin.
Vincent Lefevre wrote in message
<20080526113210$7af2@prunille.vinc17.org>:
Il n'y a pas forcément un environnement unique qui convienne à tout
le monde.
Il y a presque toujours un environnement qui convienne à la plupart des
scripts lancés sur une machine. Que cet environnement soit dupliqué dans
chacun des scripts est totalement contre-productif et crétin.
Vincent Lefevre wrote in message <20080526113210$:
Il n'y a pas forcément un environnement unique qui convienne à tout le monde.
Il y a presque toujours un environnement qui convienne à la plupart des scripts lancés sur une machine. Que cet environnement soit dupliqué dans chacun des scripts est totalement contre-productif et crétin.
