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?
C'est ainsi que je l'entends en général. L'endroit où je rencontre ce terme le plus souvent, c'est dans la norme HTML : les balises dépréciées sont déconseillées d'une part, et d'autre part elles risquent de disparaître complêtement dans une version future.
Et la raison, c'est la séparation entre le contenu (qui reste dans HTML) et la présentation (que l'on fait en CSS).
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 ?
La seconde, bien sûr. Mais pour ma part je n'ai jamais eu le besoin d'imbriquer cette syntaxe. Je m'en sers essentiellement dans les constructions du genre : wc `find ...` ou : fgrep ... `find ...` (et oui, je sais, fgrep n'est pas standard non plus)
Des collègues à moi utilisent plutôt xargs.
Cordialement, -- Olivier Miakinen
Bonjour,
Le 22/06/2008 01:03, Cyrille Lefevre a écrit :
s/deprecaded/déconseillée/ :)
C'est ainsi que je l'entends en général. L'endroit où je rencontre
ce terme le plus souvent, c'est dans la norme HTML : les balises
dépréciées sont déconseillées d'une part, et d'autre part elles
risquent de disparaître complêtement dans une version future.
Et la raison, c'est la séparation entre le contenu (qui reste dans
HTML) et la présentation (que l'on fait en CSS).
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 ?
La seconde, bien sûr. Mais pour ma part je n'ai jamais eu le besoin
d'imbriquer cette syntaxe. Je m'en sers essentiellement dans les
constructions du genre :
wc `find ...`
ou :
fgrep ... `find ...`
(et oui, je sais, fgrep n'est pas standard non plus)
C'est ainsi que je l'entends en général. L'endroit où je rencontre ce terme le plus souvent, c'est dans la norme HTML : les balises dépréciées sont déconseillées d'une part, et d'autre part elles risquent de disparaître complêtement dans une version future.
Et la raison, c'est la séparation entre le contenu (qui reste dans HTML) et la présentation (que l'on fait en CSS).
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 ?
La seconde, bien sûr. Mais pour ma part je n'ai jamais eu le besoin d'imbriquer cette syntaxe. Je m'en sers essentiellement dans les constructions du genre : wc `find ...` ou : fgrep ... `find ...` (et oui, je sais, fgrep n'est pas standard non plus)
Des collègues à moi utilisent plutôt xargs.
Cordialement, -- Olivier Miakinen
Matthieu Moy
Olivier Miakinen <om+ writes:
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 ?
La seconde, bien sûr. Mais pour ma part je n'ai jamais eu le besoin d'imbriquer cette syntaxe.
En ligne de commande, je m'en sert rarement, mais dans des scripts, ça n'est pas si rare.
Mais indépendament de ça, la syntaxe à base de parenthèses est bien plus claire, surtout quand on doit la méler à des double-quotes pour gérer correctement les espaces.
x=$(echo "$x" | sed 'whatever')
x=`echo "$x" | sed 'whatever'`
Question de gout, mais dans le premier cas, je vois immédiatement ce qu'il se passe, et si ce n'est pas le cas, mon éditeur de texte fait la correspondance des parenthèses.
-- Matthieu
Olivier Miakinen <om+news@miakinen.net> writes:
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 ?
La seconde, bien sûr. Mais pour ma part je n'ai jamais eu le besoin
d'imbriquer cette syntaxe.
En ligne de commande, je m'en sert rarement, mais dans des scripts, ça
n'est pas si rare.
Mais indépendament de ça, la syntaxe à base de parenthèses est bien
plus claire, surtout quand on doit la méler à des double-quotes pour
gérer correctement les espaces.
x=$(echo "$x" | sed 'whatever')
x=`echo "$x" | sed 'whatever'`
Question de gout, mais dans le premier cas, je vois immédiatement ce
qu'il se passe, et si ce n'est pas le cas, mon éditeur de texte fait
la correspondance des parenthèses.
La seconde, bien sûr. Mais pour ma part je n'ai jamais eu le besoin d'imbriquer cette syntaxe.
En ligne de commande, je m'en sert rarement, mais dans des scripts, ça n'est pas si rare.
Mais indépendament de ça, la syntaxe à base de parenthèses est bien plus claire, surtout quand on doit la méler à des double-quotes pour gérer correctement les espaces.
x=$(echo "$x" | sed 'whatever')
x=`echo "$x" | sed 'whatever'`
Question de gout, mais dans le premier cas, je vois immédiatement ce qu'il se passe, et si ce n'est pas le cas, mon éditeur de texte fait la correspondance des parenthèses.
-- Matthieu
Cyrille Lefevre
Stephane CHAZELAS a écrit :
2008-06-22, 03:23(+02), Cyrille Lefevre:
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.
ce devait être les prédécesseurs du ksh (bref, le bourne koi :), car en 11/16/88f (base irix), pas de pb.
pour autant, je me souviens également parser le résultat pour "not found", mais ni quand, ni ou, ni qu'est-ce !
PS : j'ai toujours eu du mal avec le C façon pascal... %/ et toi ? LOL
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Stephane CHAZELAS a écrit :
2008-06-22, 03:23(+02), Cyrille Lefevre:
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.
ce devait être les prédécesseurs du ksh (bref, le bourne koi :),
car en 11/16/88f (base irix), pas de pb.
pour autant, je me souviens également parser le résultat pour
"not found", mais ni quand, ni ou, ni qu'est-ce !
PS : j'ai toujours eu du mal avec le C façon pascal... %/ et toi ? LOL
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
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.
ce devait être les prédécesseurs du ksh (bref, le bourne koi :), car en 11/16/88f (base irix), pas de pb.
pour autant, je me souviens également parser le résultat pour "not found", mais ni quand, ni ou, ni qu'est-ce !
PS : j'ai toujours eu du mal avec le C façon pascal... %/ et toi ? LOL
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Olivier Miakinen
Le 22/06/2008 22:43, Matthieu Moy a écrit :
En ligne de commande, je m'en sert rarement, mais dans des scripts, ça n'est pas si rare.
Pour moi c'est tout le contraire. Mais il faut dire que j'écris rarement des scripts (et quand ça m'arrive, c'est le plus souvent un script à usage unique, aussitôt effacé après usage).
Mais indépendament de ça, la syntaxe à base de parenthèses est bien plus claire, surtout quand on doit la méler à des double-quotes pour gérer correctement les espaces.
x=$(echo "$x" | sed 'whatever')
x=`echo "$x" | sed 'whatever'`
Oui, c'est incontestable.
En conclusion, je penserai à utiliser $(...) pour la lisibilité si un jour je dois écrire un script dont la durée de vie soit supérieure à quelques minutes, mais pour mon usage occasionnel en ligne de commande je ne suis pas sûr de faire l'effort de changer d'habitude.
Merci à tous les deux pour vos réponses.
Le 22/06/2008 22:43, Matthieu Moy a écrit :
En ligne de commande, je m'en sert rarement, mais dans des scripts, ça
n'est pas si rare.
Pour moi c'est tout le contraire. Mais il faut dire que j'écris rarement
des scripts (et quand ça m'arrive, c'est le plus souvent un script à
usage unique, aussitôt effacé après usage).
Mais indépendament de ça, la syntaxe à base de parenthèses est bien
plus claire, surtout quand on doit la méler à des double-quotes pour
gérer correctement les espaces.
x=$(echo "$x" | sed 'whatever')
x=`echo "$x" | sed 'whatever'`
Oui, c'est incontestable.
En conclusion, je penserai à utiliser $(...) pour la lisibilité si un
jour je dois écrire un script dont la durée de vie soit supérieure à
quelques minutes, mais pour mon usage occasionnel en ligne de commande
je ne suis pas sûr de faire l'effort de changer d'habitude.
En ligne de commande, je m'en sert rarement, mais dans des scripts, ça n'est pas si rare.
Pour moi c'est tout le contraire. Mais il faut dire que j'écris rarement des scripts (et quand ça m'arrive, c'est le plus souvent un script à usage unique, aussitôt effacé après usage).
Mais indépendament de ça, la syntaxe à base de parenthèses est bien plus claire, surtout quand on doit la méler à des double-quotes pour gérer correctement les espaces.
x=$(echo "$x" | sed 'whatever')
x=`echo "$x" | sed 'whatever'`
Oui, c'est incontestable.
En conclusion, je penserai à utiliser $(...) pour la lisibilité si un jour je dois écrire un script dont la durée de vie soit supérieure à quelques minutes, mais pour mon usage occasionnel en ligne de commande je ne suis pas sûr de faire l'effort de changer d'habitude.
Merci à tous les deux pour vos réponses.
Stephane CHAZELAS
2008-06-22, 22:43(+02), Matthieu Moy: [...]
x=$(echo "$x" | sed 'whatever')
x=`echo "$x" | sed 'whatever'`
Question de gout, mais dans le premier cas, je vois immédiatement ce qu'il se passe, et si ce n'est pas le cas, mon éditeur de texte fait la correspondance des parenthèses.
Et si whatever contient des ou $ ou ` le comportement sera different.
$ x=foo; x=$(echo "$x" | grep '$'); echo $x
$ x=foo; x=`echo "$x" | grep '$'`; echo $x foo
Le pire c'est avec les doubles quotes (qu'il FAUT mettre si on veut eviter word splitting et filename generation):
echo "`echo "`echo foo`"`"
...
-- Stéphane
2008-06-22, 22:43(+02), Matthieu Moy:
[...]
x=$(echo "$x" | sed 'whatever')
x=`echo "$x" | sed 'whatever'`
Question de gout, mais dans le premier cas, je vois immédiatement ce
qu'il se passe, et si ce n'est pas le cas, mon éditeur de texte fait
la correspondance des parenthèses.
Et si whatever contient des \ ou $ ou ` le comportement sera
different.
$ x=foo; x=$(echo "$x" | grep '$'); echo $x
$ x=foo; x=`echo "$x" | grep '$'`; echo $x
foo
Le pire c'est avec les doubles quotes (qu'il FAUT mettre si on
veut eviter word splitting et filename generation):
Question de gout, mais dans le premier cas, je vois immédiatement ce qu'il se passe, et si ce n'est pas le cas, mon éditeur de texte fait la correspondance des parenthèses.
Et si whatever contient des ou $ ou ` le comportement sera different.
$ x=foo; x=$(echo "$x" | grep '$'); echo $x
$ x=foo; x=`echo "$x" | grep '$'`; echo $x foo
Le pire c'est avec les doubles quotes (qu'il FAUT mettre si on veut eviter word splitting et filename generation):
