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
Dans l'article <483d0853$0$5005$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080528025400$:
Cela a ses avantages (e.g. pas besoin de LD_LIBRARY_PATH),
Un Unix moderne correctement configuré n'a pas besoin de LD_LIBRARY_PATH, à la base.
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
C'est AMHA plus propre que sous Linux.
Est-ce qu'on peut avoir ta vision de ce qui se passe « sous Linux » ?
Le fait qu'il y ait besoin de LD_LIBRARY_PATH.
Ce n'est pas seulement pour du débuggage "actif". On peut vouloir utiliser une version d'une bibliothèque qui contient une vérification complète des assertions, par mesure de sécurité.
Ça reste quand même quelque chose d'extrêmement particulier.
Non, ce n'est pas particulier. Ça arrive assez fréquemment.
Dans l'article <483d0853$0$5005$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080528025400$788c@prunille.vinc17.org>:
Cela a ses avantages (e.g. pas besoin de LD_LIBRARY_PATH),
Un Unix moderne correctement configuré n'a pas besoin de LD_LIBRARY_PATH, à
la base.
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
C'est AMHA plus propre que sous
Linux.
Est-ce qu'on peut avoir ta vision de ce qui se passe « sous Linux » ?
Le fait qu'il y ait besoin de LD_LIBRARY_PATH.
Ce n'est pas seulement pour du débuggage "actif". On peut vouloir
utiliser une version d'une bibliothèque qui contient une vérification
complète des assertions, par mesure de sécurité.
Ça reste quand même quelque chose d'extrêmement particulier.
Non, ce n'est pas particulier. Ça arrive assez fréquemment.
Dans l'article <483d0853$0$5005$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080528025400$:
Cela a ses avantages (e.g. pas besoin de LD_LIBRARY_PATH),
Un Unix moderne correctement configuré n'a pas besoin de LD_LIBRARY_PATH, à la base.
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
C'est AMHA plus propre que sous Linux.
Est-ce qu'on peut avoir ta vision de ce qui se passe « sous Linux » ?
Le fait qu'il y ait besoin de LD_LIBRARY_PATH.
Ce n'est pas seulement pour du débuggage "actif". On peut vouloir utiliser une version d'une bibliothèque qui contient une vérification complète des assertions, par mesure de sécurité.
Ça reste quand même quelque chose d'extrêmement particulier.
Non, ce n'est pas particulier. Ça arrive assez fréquemment.
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Ce que je ne comprends pas, c'est quelle feature MacOSX est censé avoir qui le rendrait supérieur à linux sur ce point. On peut tout aussi bien spécifier un rpath à la compilation, on peut aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de la conversation.
Vincent Lefevre wrote:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Ce que je ne comprends pas, c'est quelle feature MacOSX est censé avoir
qui le rendrait supérieur à linux sur ce point. On peut tout aussi bien
spécifier un rpath à la compilation, on peut aussi utiliser des chemins
relatifs, etc. J'ai dû louper un bout de la conversation.
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Ce que je ne comprends pas, c'est quelle feature MacOSX est censé avoir qui le rendrait supérieur à linux sur ce point. On peut tout aussi bien spécifier un rpath à la compilation, on peut aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de la conversation.
Nicolas George
Vincent Lefevre wrote in message <20080528100751$:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Non.
Je ne sais pas comment tu te débrouilles, mais manifestement mal. Du coup, ce n'est pas étonnant si tu trouves macos meilleur, mais le problème n'est pas dans l'OS, il est entre la chaise et le clavier.
Vincent Lefevre wrote in message
<20080528100751$567d@prunille.vinc17.org>:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Non.
Je ne sais pas comment tu te débrouilles, mais manifestement mal. Du coup,
ce n'est pas étonnant si tu trouves macos meilleur, mais le problème n'est
pas dans l'OS, il est entre la chaise et le clavier.
Vincent Lefevre wrote in message <20080528100751$:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Non.
Je ne sais pas comment tu te débrouilles, mais manifestement mal. Du coup, ce n'est pas étonnant si tu trouves macos meilleur, mais le problème n'est pas dans l'OS, il est entre la chaise et le clavier.
Nicolas George
"Thierry B." wrote in message :
tu as plusieurs yusers qui font du bricolage un peu avancé.
Qui font du bricolage, justement.
"Thierry B." wrote in message <dfnvg5-bea.ln1@prout.stex>:
tu as plusieurs yusers qui font du bricolage un peu avancé.
tu as plusieurs yusers qui font du bricolage un peu avancé.
Qui font du bricolage, justement.
Paul Gaborit
À (at) 28 May 2008 12:30:22 GMT, Nicolas George <nicolas$ écrivait (wrote):
Vincent Lefevre wrote in message <20080528100751$:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Non.
C'est sûr, LD_LIBRARY_PATH est totalement inutile. On se demande d'ailleurs bien pourquoi *tous* les systèmes avec bibliothèques dynamiques gèrent cette fonctionnalité sous cette forme ou via un mécanisme similaire.
Je ne sais pas comment tu te débrouilles, mais manifestement mal. Du coup, ce n'est pas étonnant si tu trouves macos meilleur, mais le problème n'est pas dans l'OS, il est entre la chaise et le clavier.
C'est vrai : entre toutes les chaises (sauf la tienne) et tous les claviers du monde (sauf le tien), il n'y a que des problèmes...
;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 28 May 2008 12:30:22 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Vincent Lefevre wrote in message
<20080528100751$567d@prunille.vinc17.org>:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Non.
C'est sûr, LD_LIBRARY_PATH est totalement inutile. On se demande
d'ailleurs bien pourquoi *tous* les systèmes avec bibliothèques
dynamiques gèrent cette fonctionnalité sous cette forme ou via un
mécanisme similaire.
Je ne sais pas comment tu te débrouilles, mais manifestement mal. Du
coup, ce n'est pas étonnant si tu trouves macos meilleur, mais le
problème n'est pas dans l'OS, il est entre la chaise et le clavier.
C'est vrai : entre toutes les chaises (sauf la tienne) et tous les
claviers du monde (sauf le tien), il n'y a que des problèmes...
;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 28 May 2008 12:30:22 GMT, Nicolas George <nicolas$ écrivait (wrote):
Vincent Lefevre wrote in message <20080528100751$:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Non.
C'est sûr, LD_LIBRARY_PATH est totalement inutile. On se demande d'ailleurs bien pourquoi *tous* les systèmes avec bibliothèques dynamiques gèrent cette fonctionnalité sous cette forme ou via un mécanisme similaire.
Je ne sais pas comment tu te débrouilles, mais manifestement mal. Du coup, ce n'est pas étonnant si tu trouves macos meilleur, mais le problème n'est pas dans l'OS, il est entre la chaise et le clavier.
C'est vrai : entre toutes les chaises (sauf la tienne) et tous les claviers du monde (sauf le tien), il n'y a que des problèmes...
;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) 28 May 2008 12:30:34 GMT, Nicolas George <nicolas$ écrivait (wrote):
"Thierry B." wrote in message :
tu as plusieurs yusers qui font du bricolage un peu avancé.
Qui font du bricolage, justement.
Le bricolage, c'est l'huile des rouages informatiques : on ne peut pas faire un beau système qu'avec de l'huile mais ceux qui oublient que ça existe se demandent encore pourquoi des fois ça bloque...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 28 May 2008 12:30:34 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
"Thierry B." wrote in message <dfnvg5-bea.ln1@prout.stex>:
tu as plusieurs yusers qui font du bricolage un peu avancé.
Qui font du bricolage, justement.
Le bricolage, c'est l'huile des rouages informatiques : on ne peut pas
faire un beau système qu'avec de l'huile mais ceux qui oublient que ça
existe se demandent encore pourquoi des fois ça bloque...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 28 May 2008 12:30:34 GMT, Nicolas George <nicolas$ écrivait (wrote):
"Thierry B." wrote in message :
tu as plusieurs yusers qui font du bricolage un peu avancé.
Qui font du bricolage, justement.
Le bricolage, c'est l'huile des rouages informatiques : on ne peut pas faire un beau système qu'avec de l'huile mais ceux qui oublient que ça existe se demandent encore pourquoi des fois ça bloque...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Nicolas George
Paul Gaborit wrote in message :
C'est sûr, LD_LIBRARY_PATH est totalement inutile.
Tu as un problème avec les négations, on dirait : le contraire de « on a besoin de foo », ce n'est pas « foo est inutile ».
De fait, l'immense majorité des systèmes GNU/Linux fonctionnent parfaitement sans qu'il y ait besoin que LD_LIBRARY_PATH soit positionnée.
Paul Gaborit wrote in message <wt9hccimvod.fsf@marceau.enstimac.fr>:
C'est sûr, LD_LIBRARY_PATH est totalement inutile.
Tu as un problème avec les négations, on dirait : le contraire de « on a
besoin de foo », ce n'est pas « foo est inutile ».
De fait, l'immense majorité des systèmes GNU/Linux fonctionnent parfaitement
sans qu'il y ait besoin que LD_LIBRARY_PATH soit positionnée.
C'est sûr, LD_LIBRARY_PATH est totalement inutile.
Tu as un problème avec les négations, on dirait : le contraire de « on a besoin de foo », ce n'est pas « foo est inutile ».
De fait, l'immense majorité des systèmes GNU/Linux fonctionnent parfaitement sans qu'il y ait besoin que LD_LIBRARY_PATH soit positionnée.
Thierry B.
--{ Nicolas George a plopé ceci: }--
C'est sûr, LD_LIBRARY_PATH est totalement inutile.
Tu as un problème avec les négations, on dirait : le contraire de « on a besoin de foo », ce n'est pas « foo est inutile ».
De fait, l'immense majorité des systèmes GNU/Linux fonctionnent parfaitement sans qu'il y ait besoin que LD_LIBRARY_PATH soit positionnée.
Bien. Voyons un cas d'école. Deux yusers sur la même machine qui utilisent tous deux pgplot, mais dans des versions différentes, comment font-ils, pratiquement, pour continuer à bricoler sans l'aide de LD_LIBRARY_PATH ? C'est une vrai question.
-- Bonjour [NON] Bien à vous. Amicalement. --{ JFO, clair et net, in fufe }--
--{ Nicolas George a plopé ceci: }--
C'est sûr, LD_LIBRARY_PATH est totalement inutile.
Tu as un problème avec les négations, on dirait : le contraire de « on a
besoin de foo », ce n'est pas « foo est inutile ».
De fait, l'immense majorité des systèmes GNU/Linux fonctionnent parfaitement
sans qu'il y ait besoin que LD_LIBRARY_PATH soit positionnée.
Bien. Voyons un cas d'école. Deux yusers sur la même machine
qui utilisent tous deux pgplot, mais dans des versions différentes,
comment font-ils, pratiquement, pour continuer à bricoler sans
l'aide de LD_LIBRARY_PATH ? C'est une vrai question.
--
Bonjour [NON] Bien à vous. Amicalement.
--{ JFO, clair et net, in fufe }--
C'est sûr, LD_LIBRARY_PATH est totalement inutile.
Tu as un problème avec les négations, on dirait : le contraire de « on a besoin de foo », ce n'est pas « foo est inutile ».
De fait, l'immense majorité des systèmes GNU/Linux fonctionnent parfaitement sans qu'il y ait besoin que LD_LIBRARY_PATH soit positionnée.
Bien. Voyons un cas d'école. Deux yusers sur la même machine qui utilisent tous deux pgplot, mais dans des versions différentes, comment font-ils, pratiquement, pour continuer à bricoler sans l'aide de LD_LIBRARY_PATH ? C'est une vrai question.
-- Bonjour [NON] Bien à vous. Amicalement. --{ JFO, clair et net, in fufe }--
Nicolas George
"Thierry B." wrote in message :
Bien. Voyons un cas d'école. Deux yusers sur la même machine qui utilisent tous deux pgplot,
Déjà c'est pas crédible.
mais dans des versions différentes,
On se demande bien pourquoi.
comment font-ils, pratiquement, pour continuer à bricoler sans l'aide de LD_LIBRARY_PATH ? C'est une vrai question.
man ld /-rpath
"Thierry B." wrote in message <2dg0h5-74c.ln1@prout.stex>:
Bien. Voyons un cas d'école. Deux yusers sur la même machine
qui utilisent tous deux pgplot,
Déjà c'est pas crédible.
mais dans des versions différentes,
On se demande bien pourquoi.
comment font-ils, pratiquement, pour continuer à bricoler sans
l'aide de LD_LIBRARY_PATH ? C'est une vrai question.
Bien. Voyons un cas d'école. Deux yusers sur la même machine qui utilisent tous deux pgplot,
Déjà c'est pas crédible.
mais dans des versions différentes,
On se demande bien pourquoi.
comment font-ils, pratiquement, pour continuer à bricoler sans l'aide de LD_LIBRARY_PATH ? C'est une vrai question.
man ld /-rpath
Vincent Lefevre
Dans l'article <g1jf8b$2klu$, Marc écrit:
Vincent Lefevre wrote:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Ce que je ne comprends pas, c'est quelle feature MacOSX est censé avoir qui le rendrait supérieur à linux sur ce point.
Il stocke le chemin complet vers la bibliothèque (pas uniquement le leafname); c'est le format Mach-O.
On peut tout aussi bien spécifier un rpath à la compilation, on peut aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de la conversation.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation. Ensuite, s'il est utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...), il n'est à ma connaissance généralement pas possible de spécifier le nouvel emplacement par une variable d'environnement; bon, en fait, ça dépend du Linux: avec certaines distributions, le LD_LIBRARY_PATH est prioritaire sur le run path (que c'est bordélique...). D'autre part, le rpath est global pour toutes les bibliothèques, ce qui exclut certains combinaisons (ceci dit, en pratique, ces combinaisons ne devraient jamais arriver).
Il y a support rpath qui a été ajouté à Mac OS X 10.5, mais je n'ai pas bien compris:
Dans l'article <g1jf8b$2klu$1@nef.ens.fr>,
Marc <marc.glisse@gmail.com> écrit:
Vincent Lefevre wrote:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Ce que je ne comprends pas, c'est quelle feature MacOSX est censé
avoir qui le rendrait supérieur à linux sur ce point.
Il stocke le chemin complet vers la bibliothèque (pas uniquement
le leafname); c'est le format Mach-O.
On peut tout aussi bien spécifier un rpath à la compilation, on peut
aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de
la conversation.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas
utilisé par défaut par les outils de compilation. Ensuite, s'il est
utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage
du home de l'utilisateur, ça arrive...), il n'est à ma connaissance
généralement pas possible de spécifier le nouvel emplacement par une
variable d'environnement; bon, en fait, ça dépend du Linux: avec
certaines distributions, le LD_LIBRARY_PATH est prioritaire sur le
run path (que c'est bordélique...). D'autre part, le rpath est global
pour toutes les bibliothèques, ce qui exclut certains combinaisons
(ceci dit, en pratique, ces combinaisons ne devraient jamais arriver).
Il y a support rpath qui a été ajouté à Mac OS X 10.5, mais je n'ai
pas bien compris:
Sous Linux, il y a besoin de LD_LIBRARY_PATH en pratique.
Ce que je ne comprends pas, c'est quelle feature MacOSX est censé avoir qui le rendrait supérieur à linux sur ce point.
Il stocke le chemin complet vers la bibliothèque (pas uniquement le leafname); c'est le format Mach-O.
On peut tout aussi bien spécifier un rpath à la compilation, on peut aussi utiliser des chemins relatifs, etc. J'ai dû louper un bout de la conversation.
Tout d'abord, le principal problème de rpath, c'est qu'il n'est pas utilisé par défaut par les outils de compilation. Ensuite, s'il est utilisé, alors en cas de déplacement des bibliothèques (e.g. renommage du home de l'utilisateur, ça arrive...), il n'est à ma connaissance généralement pas possible de spécifier le nouvel emplacement par une variable d'environnement; bon, en fait, ça dépend du Linux: avec certaines distributions, le LD_LIBRARY_PATH est prioritaire sur le run path (que c'est bordélique...). D'autre part, le rpath est global pour toutes les bibliothèques, ce qui exclut certains combinaisons (ceci dit, en pratique, ces combinaisons ne devraient jamais arriver).
Il y a support rpath qui a été ajouté à Mac OS X 10.5, mais je n'ai pas bien compris:
