Discussion :

[ManusDei]

Bonjour,

je débute en Perl, et j'ai un problème pour utiliser la fonction grep inclue dans Perl.

J'ai le code suivant :

Code :

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

$res=grep($nom_fonc,"nom_de_fonctions.txt");

Je cherche à vérifier si la chaine de caractère $nom_fonc (un nom de fonction) se trouve dans le fichier nom_de_fonctions.txt (devinez ).

Selon la doc que j'ai trouvé le grep me renvoie le nombre d'occurences trouvées. Sauf que là $res me renvoie systématiquement 1, même pour des fonctions dont je sais qu'elles ne sont pas dans nom_de_fonctions.txt

Quelle est mon erreur ?

Merci pour votre aide.

[Philou67430]

La fonction grep n'a pas un prototype équivalent à celui d'Unix.

Elle prends en premier paramètre, une expression (ou un bloc de code retournant une valeur booléenne), et une liste de scalaires (et non un nom de fichier).

Dans ton cas, il faut donc ouvrir le fichier, et appliquer le grep à la lecture ligne à ligne :

Code :

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

1
2
3
4
5
6
 
open my $NOM_FONCTION, "<", "nom_de_fonctions.txt" or die "Impossible d'ouvrir 'nom_de_fonctions.txt' : $!\n";
 
if (grep /$nom_fonc/, <$NOM_FONCTION>) {
  print "$nom_fonc trouvé dans le fichier\n";
}

Ce code est simpliste. En fait, grep retourne soit un booléen (dans un contexte scalaire), soit une liste des éléments du 2e paramètre de grep qui satisfont au critère du premier paramètre.
Exemple
:

Code :

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

1
2
3
4
5
 
open my $NOM_FONCTION, "<", "nom_de_fonctions.txt" or die "Impossible d'ouvrir 'nom_de_fonctions.txt' : $!\n";
 
my @perl_subs = grep /^\s*sub\s*\w*/, <$NOM_FONCTION>;
print "Lignes contenant des fonctions perl :\n", join @perl_subs;

[ManusDei]

Merci.
Je me sers de la première version, car trouver une fonction présente dans mon fichier nom_de_fonctions active un traitement.

Pour ouvrir mon fichier j'utilise

Code :

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

open(NOM_FONCTION,"nom_de_fonction.txt");

En dehors de la non-utilisation de "die" pour les cas d'erreur, y a t'il une différence notables entre les deux écritures ?

[Philou67430]

L'usage des variables scalaires comme File handle à la place des typeglob (qui sont des barewords, c'est à dire des identifiants sans sigil, comme des mots-clés) est à mon avis à privilégier.
Cela permet de limiter l'étendue de ces variables au lieu de les définir de manière globale. Cependant, leur usage est un peu plus contraignant :
- dans certains cas, pour éviter toute ambiguité, il faut les encadrer dans des accolades lors des print (du coup, la consigne est de toujours les encadrer) :

Code :

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

print { $FILE } "Hello world !";

- il faut que le scalaire soit "indéfini" (soit undef) avant de faire l'open. Si l'on souhaite ré-utiliser un scalaire comme nouveau file handle, il faut d'abord l'indéfini :

Code :

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

1
2
3
4
5
6
 
open my $FILE, "<", "toto.txt";
# ...
undef $FILE;
open $FILE, "<", "tata.txt";
# ...

Quant à l'usage de open à trois argument au lieu de open à deux arguments, sont usage est plus souple et me semble à priori préférable (on dé-corrèle le type d'ouverture du nom du fichier).

[ManusDei]

Donc, cette écriture est correcte et respecte les "bonnes pratiques" ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
open(ECRIRE,">resultat.txt");
 
foreach $file (@files) {
   open(FILEH,$file);
   print ECRIRE { $file } "\n";
   while(<FILEH>) {
      # du traitement
   }
   close(FILEH); # optionnel ou non, vu que suivi par undef ?
   undef(FILEH);
}

[Philou67430]

Non, pas tout à fait.

Les premières bonnes pratique à adopter, sont l'ajout de "use strict" et "use warnings", qui permet de faire les premières corrections.

Voici au final comment j'écrirais ton programme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
open my $ECRIRE,">", "resultat.txt" or die "Can't open resultat.txt for writting: $!";
 
foreach my $file (@files) {
   open my $FILEH, "<", $file;
   print { $ECRIRE } $file,"\n";
   while(<$FILEH>) {
      # du traitement
   }
   close $FILEH; # optionnel, vu que suivi par undef
   undef $FILEH;
}

Mais n'oublie pas qu'en perl, TIMTOWTDI.
En particulier, l'usage des parenthèses est sujet à débat. Personnellement, je réserve l'usage des parenthèses aux fonctions que j'ai créées, et j'évite autant que faire se peut leur usage pour les functions perl. En règle générale, je les utilise toujours pour les méthodes de classe. Il faut savoir que les parenthèses sont souvent inutiles, sauf parfois, pour éviter les ambiguïtés (comme par exemple lorsque tu définis une liste dont un élément est le retour d'une fonction possédant des paramètres).

[spidermario]

Code :

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

1
2
3
4
5
6
 
open my $NOM_FONCTION, "<", "nom_de_fonctions.txt" or die "Impossible d'ouvrir 'nom_de_fonctions.txt' : $!\n";
 
if (grep /$nom_fonc/, <$NOM_FONCTION>) {
  print "$nom_fonc trouvé dans le fichier\n";
}

Ce code est simpliste. En fait, grep retourne soit un booléen (dans un contexte scalaire), soit une liste des éléments du 2e paramètre de grep qui satisfont au critère du premier paramètre.

Si $nom_fonc n’est pas une regexp, il me semble préférable de l’y protéger :

Code :

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

1
2
3
if (grep /\Q$nom_fonc/, <$NOM_FONCTION>) {
    # ...
}

Par ailleurs, la valeur de retour de grep en contexte scalaire n’est pas spéciale, c’est la valeur de toute liste évaluée en contexte scalaire : son nombre d’éléments. Ainsi, en contexte scalaire, grep renvoie le nombre d’éléments ayant satisfait le prédicat (qui peut effectivement être utilisé comme un booléen pour voir si au moins un élément l’a satisfait).

[Philou67430]

Si $nom_fonc n’est pas une regexp, il me semble préférable de l’y protéger :

Code :

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

1
2
3
if (grep /\Q$nom_fonc/, <$NOM_FONCTION>) {
    # ...
}

Tout à fait d'accord : je découvre du coup \Q ... \E, qui évite l'usage de quotemeta en dehors de la fonction (qui nécessite l'usage d'une 2e variable locale si l'on ne souhaite pas d'effet de bord sur $nom_fonc).
Par contre, ne faut-il pas ajouter le \E (ou bien ce dernier devient facultatif s'il est à la fin de la regexp) ?

Par ailleurs, la valeur de retour de grep en contexte scalaire n’est pas spéciale, c’est la valeur de toute liste évaluée en contexte scalaire : son nombre d’éléments.

Tout à fait juste. Mon explication était tout aussi simpliste que le code