[mawk] Bug a rapporter ?

Programmation
1

Salut,

Je pense avoir trouvé un bug dans awk (enfin mawk, version wheezy).

J’avais besoin de virer les tags HTML d’un fichier à la barbare, j’aurais pu le
faire en perl :

cat /tmp/html | perl -ne '{s/<.+?>/ /g; split > 0 && print}'

Mais bon, j’ai pris awk :

awk '/.*/ {gsub("<[^>]+>"," ")} NF > 0 {print}' /tmp/html

Ca marche mais je voulais faire une recherche moins avide (moins “greedy” quoi…), à la perl, seulement j’ai fait une typo :

# ATTENTION CETE COMMANDE BOUFFE LA RAM
awk '/.*/ {gsub("<.+*>"," ")} NF > 0 {print}' /tmp/html

Mon PC se retrouve à moitié bloqué dû à une allocation de memoire en boucle (un peu comme une bombe malloc…)

J’ai appris entre temps que les recherches greedy avec mawk c’est pas possible. Mais il nous reste ce bug…

Alors la question c’est : je fais un rapport sur le BTS ?

Merci d’avance.

2

Salut,

Au risque de poser une bête question, l’expression « .+* » a-t-elle du sens ? Je veux dire, il me semble que « .+ » signifie une suite d’au moins un caractère. Donc, à quoi s’applique l’astérisque ? À cette suite d’un nombre indéterminé de caractères ? Cela m’a l’air louche.

De plus, si l’on écarte l’astérisque, l’expression « <.+> » va correspondre à la plus longue suite de caractères comprise entre le caractère « < » et le caractère « > », ce qui n’est pas ce que tu veux, me semble-t-il.

3

[quote=« Taurre »]
Au risque de poser une bête question, l’expression « .+* » a-t-elle du sens [/quote]

Salut,

Non. Mais elle n’est pas censé mettre mon PC en carafe - le ‹ * › a été tapé par inadvertance. Perl fait comme si de rien n’était, ce qui me semble un comportement sain.

C’est justement là question : est ce que l’on peut considérer comme un bug ou comme une erreur de celui qui a fait le script ? A mon avis les deux, mais une simple expression rationnelle mal tapée ne devrait pas mener à ça. C’est pour ça que je lançerais bien un bug sur le BTS Debian mais je voulais avoir d’autres avis…

Au pire balancer un message d’erreur en indiquant que c’est stupide, au mieux ignorer ‹ * › comme le fait Perl :023

4

Hmm… Venant du C, j’aurais tendance à considérer qu’il s’agit d’un comportement indéterminé et que, par conséquent, un peu près tout peut arriver. Cependant, je viens de jeter un œil à la norme POSIX et il semble en effet que ce soit un comportement contraire à cette dernière.

[quote=« 9.1 Regular Expression Definitions »]invalid

This section uses the term « invalid » for certain constructs or conditions. Invalid REs shall cause the utility or function using the RE to generate an error condition. When invalid is not used, violations of the specified syntax or semantics for REs produce undefined results: this may entail an error, enabling an extended syntax for that RE, or using the construct in error as literal characters to be matched. For example, the BRE construct « {1,2,3} » does not comply with the grammar. A conforming application cannot rely on it producing an error nor matching the literal characters « {1,2,3} ».[/quote]

A priori, dans le cas d’une expression non qualifiée d’invalide, il n’y a que trois comportement possible : renvoyé une erreur, effectuer la recherche s’il s’agit d’une expression régulière « étendue » ou effectuer la recherche en considérant l’expression régulière comme du texte. Toutefois, j’ai un doute sur le caractère exhaustif ou illustratif de la liste.

5

Oui c’est un bug.

@Taurre > De manière général (POSIX ou pas) un comportement indéterminé ne doit pas aboutir à la consommation de toutes les ressources de ta machine. Sauf si ce que tu demande le nécessite.

6

Hum… En effet, cela ne me paraît pas une solution très saine. :whistle:

7

Salut,

Merci à tous les deux :slightly_smiling: Je ferais un rapport quand j’aurais un peu plus de temps…