Discussion :

[mkrzemin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[disedorgue]

Bonjour,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Avec un paramêtre (exemple: toto):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Cordialement.

[N_BaH]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[jack-ft]

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\.]$*" ???

[mkrzemin]

Bonsoir,

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

@Disedorgue: tu as visé juste!

@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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[N_BaH]

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.

[mkrzemin]

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.

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! ).
Pour ce faire, une simple approche comme la suivante est suffisante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[N_BaH]

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

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

[mkrzemin]

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

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

?

Mickaël

[N_BaH]

Par contre, tu veux dire quoi par

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

?

[...]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.

[mkrzemin]

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!
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