Action sur présence ou non d'un binaire dans le PATH
15 réponses
Kevin Denis
Bonjour,
je dois lancer un script sur plusieurs machines.
Selon les machines, j'ai a disposition ou pas certains binaires.
J'utilise le PATH pour vérifier la présence du binaire.
Cela donne:
if [ `which programme` ]
then
echo programme est là
(...)
else
echo programme n'est pas là
(...)
fi
Pour éviter des sorties sur l'écran me montrant la
localisation de 'programme' ou des messages d'erreur comme quoi 'programme'
n'est nulle part, j'ai du modifier le test par:
if [ `which programme 2>\&1 > /dev/null` ]
Pourquoi dois-je mettre un \ devant le & ? Normalement,
tout ce qui est entre `` doit être exécuté tel quel?
Ca me parait lourd comme méthode, existe t'il une manière de réaliser
mon test?
Pour éviter des sorties sur l'écran me montrant la localisation de 'programme' ou des messages d'erreur comme quoi 'programme' n'est nulle part, j'ai du modifier le test par: if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement, tout ce qui est entre `` doit être exécuté tel quel?
Le & ne devrait pas etre necessaire. Que ce passe-t-il si tu l'ommets?
Ca me parait lourd comme méthode, existe t'il une manière de réaliser mon test?
C'est lourd et incorrect.
Essaie
if command -v programme > /dev/null 2>&1; then ...
ou
exists() { command -v -- "$1" > /dev/null 2>&1 }
if exists programme; then ...
Tu as aussi la commande "type". which n'est pas une commande standard et son comportement varie d'une implementation a l'autre.
-- Stéphane
2008-06-19, 07:59(+00), Kevin Denis:
[...]
Pour éviter des sorties sur l'écran me montrant la
localisation de 'programme' ou des messages d'erreur comme quoi 'programme'
n'est nulle part, j'ai du modifier le test par:
if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement,
tout ce qui est entre `` doit être exécuté tel quel?
Le & ne devrait pas etre necessaire. Que ce passe-t-il si tu
l'ommets?
Ca me parait lourd comme méthode, existe t'il une manière de réaliser
mon test?
C'est lourd et incorrect.
Essaie
if command -v programme > /dev/null 2>&1; then
...
ou
exists() {
command -v -- "$1" > /dev/null 2>&1
}
if exists programme; then
...
Tu as aussi la commande "type". which n'est pas une commande
standard et son comportement varie d'une implementation a
l'autre.
Pour éviter des sorties sur l'écran me montrant la localisation de 'programme' ou des messages d'erreur comme quoi 'programme' n'est nulle part, j'ai du modifier le test par: if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement, tout ce qui est entre `` doit être exécuté tel quel?
Le & ne devrait pas etre necessaire. Que ce passe-t-il si tu l'ommets?
Ca me parait lourd comme méthode, existe t'il une manière de réaliser mon test?
C'est lourd et incorrect.
Essaie
if command -v programme > /dev/null 2>&1; then ...
ou
exists() { command -v -- "$1" > /dev/null 2>&1 }
if exists programme; then ...
Tu as aussi la commande "type". which n'est pas une commande standard et son comportement varie d'une implementation a l'autre.
-- Stéphane
Kevin Denis
Le 19-06-2008, Stephane CHAZELAS a écrit :
Pour éviter des sorties sur l'écran me montrant la localisation de 'programme' ou des messages d'erreur comme quoi 'programme' n'est nulle part, j'ai du modifier le test par: if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement, tout ce qui est entre `` doit être exécuté tel quel?
Le & ne devrait pas etre necessaire.
L'habitude d'utiliser 2>&1 > peut-etre? Mais la, je ne comprends plus: $ [ `which ls 2>&1 > /dev/null` ] && echo present $ $ which ls /bin/ls
???
Que ce passe-t-il si tu l'ommets?
$ [ `which ls 2> 1> /dev/null` ] && echo present -bash: command substitution: line 1: syntax error near unexpected token `1'
Ca me parait lourd comme méthode, existe t'il une manière de réaliser mon test?
C'est lourd et incorrect.
Essaie
if command -v programme > /dev/null 2>&1; then ...
parfait, c'est de plus très lisible, merci
ou
exists() { command -v -- "$1" > /dev/null 2>&1 }
if exists programme; then ...
effectivement, je garde ça sous le coude.
Tu as aussi la commande "type". which n'est pas une commande standard et son comportement varie d'une implementation a l'autre.
Ok. -- Kevin
Le 19-06-2008, Stephane CHAZELAS <stephane_chazelas@yahoo.fr> a écrit :
Pour éviter des sorties sur l'écran me montrant la
localisation de 'programme' ou des messages d'erreur comme quoi 'programme'
n'est nulle part, j'ai du modifier le test par:
if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement,
tout ce qui est entre `` doit être exécuté tel quel?
Le & ne devrait pas etre necessaire.
L'habitude d'utiliser 2>&1 > peut-etre? Mais la, je ne comprends plus:
$ [ `which ls 2>&1 > /dev/null` ] && echo present
$
$ which ls
/bin/ls
???
Que ce passe-t-il si tu l'ommets?
$ [ `which ls 2> 1> /dev/null` ] && echo present
-bash: command substitution: line 1: syntax error near unexpected token `1'
Ca me parait lourd comme méthode, existe t'il une manière de réaliser
mon test?
C'est lourd et incorrect.
Essaie
if command -v programme > /dev/null 2>&1; then
...
parfait, c'est de plus très lisible, merci
ou
exists() {
command -v -- "$1" > /dev/null 2>&1
}
if exists programme; then
...
effectivement, je garde ça sous le coude.
Tu as aussi la commande "type". which n'est pas une commande
standard et son comportement varie d'une implementation a
l'autre.
Pour éviter des sorties sur l'écran me montrant la localisation de 'programme' ou des messages d'erreur comme quoi 'programme' n'est nulle part, j'ai du modifier le test par: if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement, tout ce qui est entre `` doit être exécuté tel quel?
Le & ne devrait pas etre necessaire.
L'habitude d'utiliser 2>&1 > peut-etre? Mais la, je ne comprends plus: $ [ `which ls 2>&1 > /dev/null` ] && echo present $ $ which ls /bin/ls
???
Que ce passe-t-il si tu l'ommets?
$ [ `which ls 2> 1> /dev/null` ] && echo present -bash: command substitution: line 1: syntax error near unexpected token `1'
Ca me parait lourd comme méthode, existe t'il une manière de réaliser mon test?
C'est lourd et incorrect.
Essaie
if command -v programme > /dev/null 2>&1; then ...
parfait, c'est de plus très lisible, merci
ou
exists() { command -v -- "$1" > /dev/null 2>&1 }
if exists programme; then ...
effectivement, je garde ça sous le coude.
Tu as aussi la commande "type". which n'est pas une commande standard et son comportement varie d'une implementation a l'autre.
Ok. -- Kevin
Stephane CHAZELAS
2008-06-19, 09:28(+00), Kevin Denis: [...]
if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement, tout ce qui est entre `` doit être exécuté tel quel?
Le & ne devrait pas etre necessaire.
Oups, je voulais dire: le n'est pas necessaire.
L'habitude d'utiliser 2>&1 > peut-etre? Mais la, je ne comprends plus: $ [ `which ls 2>&1 > /dev/null` ] && echo present $ $ which ls /bin/ls
Si tu veux rediriger stdout et stderr vers /dev/null, c'est
/dev/null 2>&1
2>&1 > /dev/null
Ca redirige stderr vers le fichier "&1" et stdout vers /dev/null
Donc `which...` expands to nothing. Donc [...] est false.
2>&1 > /dev/null
ca redirige stderr vers ce sur quoi pointait stdout et stdout vers /dev/null
Je crois que ce que tu voulais dire est:
[ -n "$(which ls 2> /dev/null)" ]
Attention aux a l'interieur des `...`. Utilise $(...) plutot. Quoique dans ce cas utiliser l'un comme l'autre est incorrect.
-- Stéphane
2008-06-19, 09:28(+00), Kevin Denis:
[...]
if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement,
tout ce qui est entre `` doit être exécuté tel quel?
Le & ne devrait pas etre necessaire.
Oups, je voulais dire: le n'est pas necessaire.
L'habitude d'utiliser 2>&1 > peut-etre? Mais la, je ne comprends plus:
$ [ `which ls 2>&1 > /dev/null` ] && echo present
$
$ which ls
/bin/ls
Si tu veux rediriger stdout et stderr vers /dev/null, c'est
/dev/null 2>&1
2>&1 > /dev/null
Ca redirige stderr vers le fichier "&1" et stdout vers /dev/null
Donc `which...` expands to nothing. Donc [...] est false.
2>&1 > /dev/null
ca redirige stderr vers ce sur quoi pointait stdout et stdout
vers /dev/null
Je crois que ce que tu voulais dire est:
[ -n "$(which ls 2> /dev/null)" ]
Attention aux a l'interieur des `...`. Utilise $(...) plutot.
Quoique dans ce cas utiliser l'un comme l'autre est incorrect.
Pourquoi dois-je mettre un devant le & ? Normalement, tout ce qui est entre `` doit être exécuté tel quel?
Le & ne devrait pas etre necessaire.
Oups, je voulais dire: le n'est pas necessaire.
L'habitude d'utiliser 2>&1 > peut-etre? Mais la, je ne comprends plus: $ [ `which ls 2>&1 > /dev/null` ] && echo present $ $ which ls /bin/ls
Si tu veux rediriger stdout et stderr vers /dev/null, c'est
/dev/null 2>&1
2>&1 > /dev/null
Ca redirige stderr vers le fichier "&1" et stdout vers /dev/null
Donc `which...` expands to nothing. Donc [...] est false.
2>&1 > /dev/null
ca redirige stderr vers ce sur quoi pointait stdout et stdout vers /dev/null
Je crois que ce que tu voulais dire est:
[ -n "$(which ls 2> /dev/null)" ]
Attention aux a l'interieur des `...`. Utilise $(...) plutot. Quoique dans ce cas utiliser l'un comme l'autre est incorrect.
-- Stéphane
Cyrille Lefevre
Kevin Denis a écrit : [snip]
Pour éviter des sorties sur l'écran me montrant la localisation de 'programme' ou des messages d'erreur comme quoi 'progra mme' n'est nulle part, j'ai du modifier le test par: if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement, tout ce qui est entre `` doit être exécuté tel quel?
Bonjour,
les ` sont "deprecated", utilise plutôt $(...) à la place, auquel cas tu n'as pas besoin de protéger ladit expression, ce qui donne :
[ $(which progname > /dev/null 2>&1) ]
PS : l'ordre des redirections est important. 2>&1 > /dev/null n'as pas du tout le même effet que > /dev/null 2>&1.
PS bis: pourquoi ne pas tester le code retour de which (ou type qui est bien plus portable) ? ex. : if type programme > /dev/null 2>&1
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Kevin Denis a écrit :
[snip]
Pour éviter des sorties sur l'écran me montrant la
localisation de 'programme' ou des messages d'erreur comme quoi 'progra mme'
n'est nulle part, j'ai du modifier le test par:
if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement,
tout ce qui est entre `` doit être exécuté tel quel?
Bonjour,
les ` sont "deprecated", utilise plutôt $(...) à la place, auquel cas tu
n'as pas besoin de protéger ladit expression, ce qui donne :
[ $(which progname > /dev/null 2>&1) ]
PS : l'ordre des redirections est important. 2>&1 > /dev/null
n'as pas du tout le même effet que > /dev/null 2>&1.
PS bis: pourquoi ne pas tester le code retour de which (ou type qui est
bien plus portable) ? ex. :
if type programme > /dev/null 2>&1
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
Pour éviter des sorties sur l'écran me montrant la localisation de 'programme' ou des messages d'erreur comme quoi 'progra mme' n'est nulle part, j'ai du modifier le test par: if [ `which programme 2>&1 > /dev/null` ]
Pourquoi dois-je mettre un devant le & ? Normalement, tout ce qui est entre `` doit être exécuté tel quel?
Bonjour,
les ` sont "deprecated", utilise plutôt $(...) à la place, auquel cas tu n'as pas besoin de protéger ladit expression, ce qui donne :
[ $(which progname > /dev/null 2>&1) ]
PS : l'ordre des redirections est important. 2>&1 > /dev/null n'as pas du tout le même effet que > /dev/null 2>&1.
PS bis: pourquoi ne pas tester le code retour de which (ou type qui est bien plus portable) ? ex. : if type programme > /dev/null 2>&1
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Olivier Miakinen
Le 20/06/2008 10:25, Cyrille Lefevre a écrit :
les ` sont "deprecated", utilise plutôt $(...) à la place
Ah zut, encore une mauvaise habitude dont je vais avoir à me défaire. Est-ce que tu sais pourquoi ils le sont ?
Le 20/06/2008 10:25, Cyrille Lefevre a écrit :
les ` sont "deprecated", utilise plutôt $(...) à la place
Ah zut, encore une mauvaise habitude dont je vais avoir à me défaire.
Est-ce que tu sais pourquoi ils le sont ?
les ` sont "deprecated", utilise plutôt $(...) à la place
Ah zut, encore une mauvaise habitude dont je vais avoir à me défair e. Est-ce que tu sais pourquoi ils le sont ?
Bonjour,
s/deprecaded/déconseillée/ :)
pour les raisons que j'ai avancée :
par exemple :
echo `echo `echo `echo coucou```
donne :
echo $(echo $(echo $(echo coucou)))
quelle notation te semble la plus lisible ?
PS : deprecaded == déprécié en français dans le texte... mais je ne m'en souvenait plus lors de la rédaction !
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Cyrille Lefevre
Matthieu Moy a écrit :
Cyrille Lefevre <cyrille.lefevre-news% writes:
which (ou type qui est bien plus portable)
Il parait que « command » (ou « command -v ») est le plus porta ble.
Bonjour,
reprenons au début, il était une fois, SystemV vs. BSD, etc.
sysv => bourne shell => type (builtin) bsd => csh => which (script csh)
pour autant, on trouve aussi le bourne shell sous bsd, mais pas nécessairement l'inverse -- je parle toujours des origines --
depuis, nous avons toujours eu un équivalent, sous la forme d'un alias sur whence -v en ksh par ex. d'après posix, ce serait l'équivalent à command -V, -v ne retournant que le chemin de l'argument, alors que type retourne aussi le type de l'argument (builtin, alias, etc.). à ce propos, posix (susv3) documente la commande type...
bref, type à toujours existé, et existera surement toujours.
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Il parait que « command » (ou « command -v ») est le plus porta ble.
Bonjour,
reprenons au début, il était une fois, SystemV vs. BSD, etc.
sysv => bourne shell => type (builtin)
bsd => csh => which (script csh)
pour autant, on trouve aussi le bourne shell sous bsd, mais pas
nécessairement l'inverse -- je parle toujours des origines --
depuis, nous avons toujours eu un équivalent, sous la forme d'un alias
sur whence -v en ksh par ex. d'après posix, ce serait l'équivalent à
command -V, -v ne retournant que le chemin de l'argument, alors que
type retourne aussi le type de l'argument (builtin, alias, etc.).
à ce propos, posix (susv3) documente la commande type...
bref, type à toujours existé, et existera surement toujours.
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
Il parait que « command » (ou « command -v ») est le plus porta ble.
Bonjour,
reprenons au début, il était une fois, SystemV vs. BSD, etc.
sysv => bourne shell => type (builtin) bsd => csh => which (script csh)
pour autant, on trouve aussi le bourne shell sous bsd, mais pas nécessairement l'inverse -- je parle toujours des origines --
depuis, nous avons toujours eu un équivalent, sous la forme d'un alias sur whence -v en ksh par ex. d'après posix, ce serait l'équivalent à command -V, -v ne retournant que le chemin de l'argument, alors que type retourne aussi le type de l'argument (builtin, alias, etc.). à ce propos, posix (susv3) documente la commande type...
bref, type à toujours existé, et existera surement toujours.
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Stephane CHAZELAS
2008-06-22, 03:23(+02), Cyrille Lefevre: [...]
depuis, nous avons toujours eu un équivalent, sous la forme d'un alias sur whence -v en ksh par ex. d'après posix, ce serait l'équivalent à command -V, -v ne retournant que le chemin de l'argument, alors que type retourne aussi le type de l'argument (builtin, alias, etc.). à ce propos, posix (susv3) documente la commande type...
Note que "type" n'est pas POSIX, seulement Unix (XSI extension dans SUSv3). "command -v" est POSIX mais est optionel. C'est pour ca que par exemple "posh" n'a ni l'un ni l'autre.
bref, type à toujours existé, et existera surement toujours.
Non, "type" n'est pas dans tous les Bourne shells (a ete ajoute dans SVR2 (1984) et son exit status n'a pas toujours permis de savoir si la commande existait ou non, il fallait parser le resultat pour "not found"). Il me semble, mais je peux me tromper qu'il n'etait pas dans les premiers ksh88 non plus.
Parmis les shells POSIX, je ne connais que "posh" qui ne l'ait pas. Il y a un bug report a ce sujet. Pas que ce soit un bug, mais n'avoir ni "command -v" ni "type" fait qu'il manque une fonctionnalité essentielle a ce shell.
LSB (le /standard/ Linux) n'a ni type, ni command (pourtant POSIX, seules -v et -V sont optionnels), ni which, ni whence, ni where.
-- Stéphane
2008-06-22, 03:23(+02), Cyrille Lefevre:
[...]
depuis, nous avons toujours eu un équivalent, sous la forme d'un alias
sur whence -v en ksh par ex. d'après posix, ce serait l'équivalent à
command -V, -v ne retournant que le chemin de l'argument, alors que
type retourne aussi le type de l'argument (builtin, alias, etc.).
à ce propos, posix (susv3) documente la commande type...
Note que "type" n'est pas POSIX, seulement Unix (XSI extension
dans SUSv3). "command -v" est POSIX mais est optionel. C'est
pour ca que par exemple "posh" n'a ni l'un ni l'autre.
bref, type à toujours existé, et existera surement toujours.
Non, "type" n'est pas dans tous les Bourne shells (a ete ajoute
dans SVR2 (1984) et son exit status n'a pas toujours permis
de savoir si la commande existait ou non, il fallait parser le
resultat pour "not found"). Il me semble, mais je peux me
tromper qu'il n'etait pas dans les premiers ksh88 non plus.
Parmis les shells POSIX, je ne connais que "posh" qui ne l'ait
pas. Il y a un bug report a ce sujet. Pas que ce soit un bug,
mais n'avoir ni "command -v" ni "type" fait qu'il manque une
fonctionnalité essentielle a ce shell.
LSB (le /standard/ Linux) n'a ni type, ni command (pourtant
POSIX, seules -v et -V sont optionnels), ni which, ni whence, ni
where.
depuis, nous avons toujours eu un équivalent, sous la forme d'un alias sur whence -v en ksh par ex. d'après posix, ce serait l'équivalent à command -V, -v ne retournant que le chemin de l'argument, alors que type retourne aussi le type de l'argument (builtin, alias, etc.). à ce propos, posix (susv3) documente la commande type...
Note que "type" n'est pas POSIX, seulement Unix (XSI extension dans SUSv3). "command -v" est POSIX mais est optionel. C'est pour ca que par exemple "posh" n'a ni l'un ni l'autre.
bref, type à toujours existé, et existera surement toujours.
Non, "type" n'est pas dans tous les Bourne shells (a ete ajoute dans SVR2 (1984) et son exit status n'a pas toujours permis de savoir si la commande existait ou non, il fallait parser le resultat pour "not found"). Il me semble, mais je peux me tromper qu'il n'etait pas dans les premiers ksh88 non plus.
Parmis les shells POSIX, je ne connais que "posh" qui ne l'ait pas. Il y a un bug report a ce sujet. Pas que ce soit un bug, mais n'avoir ni "command -v" ni "type" fait qu'il manque une fonctionnalité essentielle a ce shell.
LSB (le /standard/ Linux) n'a ni type, ni command (pourtant POSIX, seules -v et -V sont optionnels), ni which, ni whence, ni where.
