Changement de comportement du script bash si argument fourni

Bonsoir à toutes et à tous,

J'ai un script bash qui tente de retrouver les versions de PERL installées sur un station Linux (Fedora dans mon cas).
Si je lance le script SANS argument, le fichier test.txt contient bien l'ensemble des versions PERL installées sur mon ordinateur. En revanche, si je lance le script AVEC un argument, le fichier test.txt est vide!

Voici le script:

Code:

---

1 2 3 4 5

#!/bin/bash cat /dev/null > test.txt for __ENS_LOOPI__ in `echo $PATH | sed 's/:/ /g'`; do ls -B --color='never' -w 1 ${__ENS_LOOPI__}/perl* 2>/dev/null | grep -i "perl[0-9\.]$*" | sed 's#[*@~]$##' 1>> test.txt done

---

Une idée ?

Merci par avance,
Mickaël

Bonjour,

La dépendance se situe sur le "grep":
Sans paramêtre, cela donne:

Code:

---

grep -i "perl[0-9\.]"

---

Avec un paramêtre (exemple: toto):

Code:

---

grep -i "perl[0-9\.]toto"

---

Cordialement.

Code:

---

1 2	$ find ${PATH//:/ } -type f -regex '.*perl[0-9].*' -printf '%f\n' perl5.14.2

---

moins il y a de commandes, moins c'est facile de se tromper. ;)

Citation:

---

Envoyé par disedorgue

Bonjour,

La dépendance se situe sur le "grep":

---

Farpaitement!

"$*" s'expanse en tous les arguments.

Que voulais-tu dire avec $* dans grep -i "perl[0-9\.]$*" ???

Bonsoir,

Avant tout, merci pour vos excellentes remarques qui m'ont permis de trouver la solution! :)

@Disedorgue: tu as visé juste! :ccool:

@N_Bah: En effet, moins il y a de commandes, moins il y a d'erreurs. Cependant, moins il y a de commandes, moins c'est portable! ;)
En général, l'intérêt d'avoir de nombreuses commandes repose sur la portabilité, en utilisant des commandes aussi basiques que possibles.
Dans ton cas, par exemple, si quelqu'un a (Je ne sais pour quelle raison) dans sa variable d'environnement $PATH un chemin non pertinent, alors ta commande retournera quelquechose du genre "/chemin/non/pertinent: No such file or directory"

@jack-ft: Simple erreur de typo. Ca devrait être "*$" afin de préciser que l'élément doit terminer la ligne. Le fait d'avoir fait cette erreur de typo donne tout son sens aux résultats que j'obtenais. Par exemple, /usr/bin/perl était sélectionné alors qu'il ne devait pas l'être!

En conclusion, afin que les éléments suivants soient sélectionnés:
/usr/bin/perl5.10.1
/usr/bin/perl5.8.8

Mais pas les suivants:
/usr/bin/perl
/usr/bin/perl5.10.1blabla
/usr/bin/perlbug

La solution est:

Code:

---

1 2 3 4 5 6

#!/bin/bash cat /dev/null > test.txt for __ENS_LOOPI__ in `echo $PATH | sed 's/:/ /g'`; do ls -B --color='never' -w 1 ${__ENS_LOOPI__}/perl* 2>/dev/null | grep -i "perl[0-9][0-9\.]*$" | sed 's#[*@~]$##' 1>> test.txt done

---

Encore merci,
Mickaël

Citation:

---

Envoyé par mkrzemin

Dans ton cas, par exemple, si quelqu'un a (Je ne sais pour quelle raison) dans sa variable d'environnement $PATH un chemin non pertinent, alors ta commande retournera quelquechose du genre "/chemin/non/pertinent: No such file or directory"

---

cette remarque s'applique également à ton code.

pour info :
sed n'est pas totalement portable.
pareil pour grep, et ls.

l'uuoc, lui, est parfaitement portable. :mrgreen:

Citation:

---

Envoyé par N_BaH

cette remarque s'applique également à ton code.

pour info :
sed n'est pas totalement portable.
pareil pour grep, et ls.

l'uuoc, lui, est parfaitement portable. :mrgreen:

---

Oui oui, tout à fait, et c'est pourquoi au début de mon code, je vérifie que ces fonctions (qui sont basiques dans l'immense majorité des distributions Linux) sont présentes, auquel cas contraire, le programme s'arrête et avertit l'utilisateur (Non mais, ça veut utiliser mon programme et ça n'a même pas ces fonctions de base! :fessee: ).
Pour ce faire, une simple approche comme la suivante est suffisante:

Code:

---

1 2 3 4

__ENS_BASIC_CMDS__=( pwd head awk sed cat more grep wc dirname mkdir ) for __ENS_LOOPI__ in ${__ENS_BASIC_CMDS__[@]}; do type -P $__ENS_LOOPI__ 2>/dev/null && continue || { print "The $__ENS_LOOPI__ command cannot be found on this station. The installation will be aborting\n"; exit 1; } done

---

Sinon, pour l'uuoc, c'est une excellente remarque. Et en effet, on devrait y prêter plus attention. Dans mon code, je devrais plutôt utiliser un touch ou un print, mais c'est devenu presqu'un réflexe que de créer un fichier vide de cette manière là! ;)

Mickaël

> fichierÀvider #ou à créer suffit.

pwd est une commande intégrée de bash, mais pas print. t'es passé à ksh ?

Citation:

---

Envoyé par N_BaH

pwd est une commande intégrée de bash, mais pas print. t'es passé à ksh ?

---

Houlà! En effet, il faudrait que je fasse plus de copier/coller au lieu de recopier les lignes avec des erreurs. Il s'agit de printf qui est une commande "Built-in".

Par contre, tu veux dire quoi par

Citation:

---

Envoyé par N_BaH

> fichierÀvider #ou à créer suffit.

---

?

Mickaël

Citation:

---

Envoyé par mkrzemin

Par contre, tu veux dire quoi par

Citation:

---

Envoyé par N_BaH

> fichierÀvider #ou à créer suffit.

---

?

---

Citation:

---

Envoyé par man BASH /Redirection de sortie

[...]Si le fichier n'existe pas, il est créé. S'il existait déjà, sa taille est réduite à zéro.

---

il ne faut pas confondre printf avec echo.
qui peut le plus peut le moins, cependant printf est mieux utilisé pour le formatage des données, que pour leur simple affichage.
de la même manière, echo ne devrait pas être utilisé lorsqu'il faut afficher des données sous un certain format.

Citation:

---

Envoyé par N_BaH

il ne faut pas confondre printf avec echo.
qui peut le plus peut le moins, cependant printf est mieux utilisé pour le formatage des données, que pour leur simple affichage.
de la même manière, echo ne devrait pas être utilisé lorsqu'il faut afficher des données sous un certain format.

---

Entièrement d'accord avec toi! :mrgreen:
Il y a de grandes différences entre les deux, ne serait-ce que le "exit status". Avec printf aussi, il est plus pratique de gérer les caractères spéciaux (avec echo, sur certaines stations, il arrive que les flags qui permettent d'interpréter les caractères spéciaux ne fonctionnent pas).
J'ai juste une préférence pour le printf car je suis un grand fan du langage C! ;)
Enfin, pour echo, je serai un peu plus strict que toi et je dirais qu'il ne PEUT pas être utilisé pour afficher des données sous un certain format!

Mickaël