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 <20080602102003$:
et la page man de ld.so n'indique rien qui pourrait résoudre le problème
Moi j'y lis mention de $PLATFORM. Tu es de mauvaise foi.
Vincent Lefevre
Dans l'article <4843d301$0$26595$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080602102003$:
et la page man de ld.so n'indique rien qui pourrait résoudre le problème
Moi j'y lis mention de $PLATFORM. Tu es de mauvaise foi.
Je ne vois pas en quoi $PLATFORM résout le problème, surtout dans la mesure où les valeurs de $PLATFORM ne sont pas standardisées (et documentées nulle part il me semble).
Dans l'article <4843d301$0$26595$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Vincent Lefevre wrote in message
<20080602102003$6502@prunille.vinc17.org>:
et la page man de ld.so n'indique
rien qui pourrait résoudre le problème
Moi j'y lis mention de $PLATFORM. Tu es de mauvaise foi.
Je ne vois pas en quoi $PLATFORM résout le problème, surtout dans
la mesure où les valeurs de $PLATFORM ne sont pas standardisées
(et documentées nulle part il me semble).
Dans l'article <4843d301$0$26595$, Nicolas George <nicolas$ écrit:
Vincent Lefevre wrote in message <20080602102003$:
et la page man de ld.so n'indique rien qui pourrait résoudre le problème
Moi j'y lis mention de $PLATFORM. Tu es de mauvaise foi.
Je ne vois pas en quoi $PLATFORM résout le problème, surtout dans la mesure où les valeurs de $PLATFORM ne sont pas standardisées (et documentées nulle part il me semble).
Vincent Lefevre wrote in message <20080602105618$:
N'empêche que cela justifie pleinement l'écriture d'un wrapper modifiant le LD_LIBRARY_PATH
Je ne trouve pas.
D'autre part, ce n'est qu'un exemple. L'utilisateur peut être amené à faire le même genre de manip pour d'autres choses.
Et tu entends prouver quoi, avec ça ? Je n'ai jamais prétendu qu'il n'était jamais utile ou nécessaire de modifier LD_LIBRARY_PATH, j'ai dit -- et je maintiens -- que cette variable n'était pas nécessaire en utilisation courante sur un système bien configuré et installé.
Vincent Lefevre wrote in message
<20080602105618$1047@prunille.vinc17.org>:
N'empêche que cela justifie pleinement l'écriture d'un wrapper
modifiant le LD_LIBRARY_PATH
Je ne trouve pas.
D'autre part, ce n'est qu'un exemple. L'utilisateur peut être
amené à faire le même genre de manip pour d'autres choses.
Et tu entends prouver quoi, avec ça ? Je n'ai jamais prétendu qu'il n'était
jamais utile ou nécessaire de modifier LD_LIBRARY_PATH, j'ai dit -- et je
maintiens -- que cette variable n'était pas nécessaire en utilisation
courante sur un système bien configuré et installé.
Vincent Lefevre wrote in message <20080602105618$:
N'empêche que cela justifie pleinement l'écriture d'un wrapper modifiant le LD_LIBRARY_PATH
Je ne trouve pas.
D'autre part, ce n'est qu'un exemple. L'utilisateur peut être amené à faire le même genre de manip pour d'autres choses.
Et tu entends prouver quoi, avec ça ? Je n'ai jamais prétendu qu'il n'était jamais utile ou nécessaire de modifier LD_LIBRARY_PATH, j'ai dit -- et je maintiens -- que cette variable n'était pas nécessaire en utilisation courante sur un système bien configuré et installé.
Jean-Marc Bourguet
Nicolas George <nicolas$ writes:
Vincent Lefevre wrote in message <20080602102003$:
et la page man de ld.so n'indique rien qui pourrait résoudre le problème
Moi j'y lis mention de $PLATFORM. Tu es de mauvaise foi.
Je ne vois rien ni sur le site que j'ai donne, ni sur les deux versions differentes entre elles avec celle du site auxquels j'ai acces.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Nicolas George <nicolas$george@salle-s.org> writes:
Vincent Lefevre wrote in message
<20080602102003$6502@prunille.vinc17.org>:
et la page man de ld.so n'indique
rien qui pourrait résoudre le problème
Moi j'y lis mention de $PLATFORM. Tu es de mauvaise foi.
Je ne vois rien ni sur le site que j'ai donne, ni sur les deux versions
differentes entre elles avec celle du site auxquels j'ai acces.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Donc, pour x86, c'est la meme chose que uname -m. Pour le reste, difficile a dire a la lecture des sources du kernel.
-- Stéphane
Jean-Marc Bourguet
Stephane CHAZELAS writes:
2008-06-02, 13:25(+02), Jean-Marc Bourguet:
Nicolas George <nicolas$ writes:
Vincent Lefevre wrote in message <20080602102003$:
et la page man de ld.so n'indique rien qui pourrait résoudre le problème
Moi j'y lis mention de $PLATFORM. Tu es de mauvaise foi.
Je ne vois rien ni sur le site que j'ai donne, ni sur les deux versions differentes entre elles avec celle du site auxquels j'ai acces. [...]
On peut l'obtenir en faisant un
LD_SHOW_AUXV=1 /bin/true (pas documenté non plus)
mais je ne suis pas sur de ou ca vient.
Ca ressemble a uname -m
Non. Ca donne x86_64 ou i686 sur deux executables differents, un 64 et un 32 bits. Ca ressemble a ce que objdump -a donne, mais sans le {elf32-,elf64-}.
Mais je n'ai pas vu non plus de doc (a part celle de Sun), decrivant que c'est utilisable dans DT_R{,UN}PATH.
En passant, je ne comprends pas pourquoi --enable-new-dtags n'est toujours pas le defaut (tout le monde est d'accord je crois que le fait que DT_RPATH ait priorite sur LD_LIBRARY_PATH ou equivalent est un probleme -- du moins c'est la raison pour laquelle DT_RUNPATH a ete introduit et que sa presence inhibibe DT_RPATH).
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Nicolas George <nicolas$george@salle-s.org> writes:
Vincent Lefevre wrote in message
<20080602102003$6502@prunille.vinc17.org>:
et la page man de ld.so n'indique
rien qui pourrait résoudre le problème
Moi j'y lis mention de $PLATFORM. Tu es de mauvaise foi.
Je ne vois rien ni sur le site que j'ai donne, ni sur les deux versions
differentes entre elles avec celle du site auxquels j'ai acces.
[...]
On peut l'obtenir en faisant un
LD_SHOW_AUXV=1 /bin/true
(pas documenté non plus)
mais je ne suis pas sur de ou ca vient.
Ca ressemble a uname -m
Non. Ca donne x86_64 ou i686 sur deux executables differents, un 64 et un
32 bits. Ca ressemble a ce que objdump -a donne, mais sans le
{elf32-,elf64-}.
Mais je n'ai pas vu non plus de doc (a part celle de Sun), decrivant que
c'est utilisable dans DT_R{,UN}PATH.
En passant, je ne comprends pas pourquoi --enable-new-dtags n'est toujours
pas le defaut (tout le monde est d'accord je crois que le fait que DT_RPATH
ait priorite sur LD_LIBRARY_PATH ou equivalent est un probleme -- du moins
c'est la raison pour laquelle DT_RUNPATH a ete introduit et que sa presence
inhibibe DT_RPATH).
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre wrote in message <20080602102003$:
et la page man de ld.so n'indique rien qui pourrait résoudre le problème
Moi j'y lis mention de $PLATFORM. Tu es de mauvaise foi.
Je ne vois rien ni sur le site que j'ai donne, ni sur les deux versions differentes entre elles avec celle du site auxquels j'ai acces. [...]
On peut l'obtenir en faisant un
LD_SHOW_AUXV=1 /bin/true (pas documenté non plus)
mais je ne suis pas sur de ou ca vient.
Ca ressemble a uname -m
Non. Ca donne x86_64 ou i686 sur deux executables differents, un 64 et un 32 bits. Ca ressemble a ce que objdump -a donne, mais sans le {elf32-,elf64-}.
Mais je n'ai pas vu non plus de doc (a part celle de Sun), decrivant que c'est utilisable dans DT_R{,UN}PATH.
En passant, je ne comprends pas pourquoi --enable-new-dtags n'est toujours pas le defaut (tout le monde est d'accord je crois que le fait que DT_RPATH ait priorite sur LD_LIBRARY_PATH ou equivalent est un probleme -- du moins c'est la raison pour laquelle DT_RUNPATH a ete introduit et que sa presence inhibibe DT_RPATH).
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre
Dans l'article , Stephane CHAZELAS écrit:
On peut l'obtenir en faisant un
LD_SHOW_AUXV=1 /bin/true (pas documenté non plus)
mais je ne suis pas sur de ou ca vient.
Ca ressemble a uname -m
Ce n'est pas suffisant: cela indique l'architecture (x86_64), mais pas le type de processeur (Intel Pentium, Intel Core2, AMD Opteron, etc.). Or c'est bien le type de processeur qui est essentiel dans ce cas précis.
Dans l'article <slrng47nhg.nm3.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> écrit:
On peut l'obtenir en faisant un
LD_SHOW_AUXV=1 /bin/true
(pas documenté non plus)
mais je ne suis pas sur de ou ca vient.
Ca ressemble a uname -m
Ce n'est pas suffisant: cela indique l'architecture (x86_64), mais
pas le type de processeur (Intel Pentium, Intel Core2, AMD Opteron,
etc.). Or c'est bien le type de processeur qui est essentiel dans
ce cas précis.
Ce n'est pas suffisant: cela indique l'architecture (x86_64), mais pas le type de processeur (Intel Pentium, Intel Core2, AMD Opteron, etc.). Or c'est bien le type de processeur qui est essentiel dans ce cas précis.
Dans l'article <4843d5d4$0$15447$, Nicolas George <nicolas$ écrit:
Et tu entends prouver quoi, avec ça ? Je n'ai jamais prétendu qu'il n'était jamais utile ou nécessaire de modifier LD_LIBRARY_PATH, j'ai dit -- et je maintiens -- que cette variable n'était pas nécessaire en utilisation courante sur un système bien configuré et installé.
Je fais une utilisation de GMP de manière courante (en fait, *tous* les jours), et il y a besoin de cette variable. Tout du moins c'est ce qui est le plus pratique. (Il y a peut-être un moyen de faire sans elle, avec les fat binaries, que GMP supporte maintenant.)
D'autre part, le LD_LIBRARY_PATH reste le moyen le plus portable, sinon cela demande des options de compilation non standard pour utiliser le run path (ce qui peut poser problème car je ne connais pas toutes les plateformes), et je fais ainsi (par script) plusieurs milliers de compilation par jour, donc c'est aussi une utilisation courante.
Dans l'article <4843d5d4$0$15447$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Et tu entends prouver quoi, avec ça ? Je n'ai jamais prétendu qu'il
n'était jamais utile ou nécessaire de modifier LD_LIBRARY_PATH, j'ai
dit -- et je maintiens -- que cette variable n'était pas nécessaire
en utilisation courante sur un système bien configuré et installé.
Je fais une utilisation de GMP de manière courante (en fait, *tous*
les jours), et il y a besoin de cette variable. Tout du moins c'est
ce qui est le plus pratique. (Il y a peut-être un moyen de faire
sans elle, avec les fat binaries, que GMP supporte maintenant.)
D'autre part, le LD_LIBRARY_PATH reste le moyen le plus portable,
sinon cela demande des options de compilation non standard pour
utiliser le run path (ce qui peut poser problème car je ne connais
pas toutes les plateformes), et je fais ainsi (par script) plusieurs
milliers de compilation par jour, donc c'est aussi une utilisation
courante.
Dans l'article <4843d5d4$0$15447$, Nicolas George <nicolas$ écrit:
Et tu entends prouver quoi, avec ça ? Je n'ai jamais prétendu qu'il n'était jamais utile ou nécessaire de modifier LD_LIBRARY_PATH, j'ai dit -- et je maintiens -- que cette variable n'était pas nécessaire en utilisation courante sur un système bien configuré et installé.
Je fais une utilisation de GMP de manière courante (en fait, *tous* les jours), et il y a besoin de cette variable. Tout du moins c'est ce qui est le plus pratique. (Il y a peut-être un moyen de faire sans elle, avec les fat binaries, que GMP supporte maintenant.)
D'autre part, le LD_LIBRARY_PATH reste le moyen le plus portable, sinon cela demande des options de compilation non standard pour utiliser le run path (ce qui peut poser problème car je ne connais pas toutes les plateformes), et je fais ainsi (par script) plusieurs milliers de compilation par jour, donc c'est aussi une utilisation courante.
Pour citer un cas peu fréquent (une fois par an...) où le LD_LIBRARY_PATH a un intérêt : Cf http://olivierberger.com/weblog/index.php/2008/05/18/103-declaration-d-impots-sous-debian-testing-difficultes-mais-contournement-trouve « Mais j'ai trouvé le contournement suivant pour que ça passe (après avoir complètement quitté iceweasel) : lancer iceweasel depuis le répertoire contenant libnss3.so, avec LD_LIBRARY_PATH positionnée à "." :
$ cd /usr/lib/iceweasel/ $ LD_LIBRARY_PATH=. iceweasel » (ça concerne au moins Debian Etch et Debian Sid)
Comme noté dans des réponses de ce blog, il est inutile de mettre soi-même LD_LIBRARY_PATH (c'est la première chose que fait le script de lancement de firefox).
Quant au reste, j'ai déclaré mes impôts avec java6 sur debian testing avec PWD=$HOME (ça a planté une fois, mais pas la seconde), donc je ne sais pas trop d'où vient le problème.
Benoit SIBAUD wrote:
Pour citer un cas peu fréquent (une fois par an...) où le
LD_LIBRARY_PATH a un intérêt :
Cf
http://olivierberger.com/weblog/index.php/2008/05/18/103-declaration-d-impots-sous-debian-testing-difficultes-mais-contournement-trouve
«
Mais j'ai trouvé le contournement suivant pour que ça passe (après avoir
complètement quitté iceweasel) : lancer iceweasel depuis le répertoire
contenant libnss3.so, avec LD_LIBRARY_PATH positionnée à "." :
$ cd /usr/lib/iceweasel/
$ LD_LIBRARY_PATH=. iceweasel
»
(ça concerne au moins Debian Etch et Debian Sid)
Comme noté dans des réponses de ce blog, il est inutile de mettre
soi-même LD_LIBRARY_PATH (c'est la première chose que fait le script de
lancement de firefox).
Quant au reste, j'ai déclaré mes impôts avec java6 sur debian testing
avec PWD=$HOME (ça a planté une fois, mais pas la seconde), donc je ne
sais pas trop d'où vient le problème.
Pour citer un cas peu fréquent (une fois par an...) où le LD_LIBRARY_PATH a un intérêt : Cf http://olivierberger.com/weblog/index.php/2008/05/18/103-declaration-d-impots-sous-debian-testing-difficultes-mais-contournement-trouve « Mais j'ai trouvé le contournement suivant pour que ça passe (après avoir complètement quitté iceweasel) : lancer iceweasel depuis le répertoire contenant libnss3.so, avec LD_LIBRARY_PATH positionnée à "." :
$ cd /usr/lib/iceweasel/ $ LD_LIBRARY_PATH=. iceweasel » (ça concerne au moins Debian Etch et Debian Sid)
Comme noté dans des réponses de ce blog, il est inutile de mettre soi-même LD_LIBRARY_PATH (c'est la première chose que fait le script de lancement de firefox).
Quant au reste, j'ai déclaré mes impôts avec java6 sur debian testing avec PWD=$HOME (ça a planté une fois, mais pas la seconde), donc je ne sais pas trop d'où vient le problème.
