J'ai un comportement curieux avec un sous-programme qui n'est pas reconnu en
tant que sous programme par Perl. Voici l'extrait du code concerné :
#!/usr/bin/perl -w
use strict;
...
sub uniq(@); # declaration
...
# conserver un exemplaire unique de chaque element de la liste
sub uniq(@) {
my %mark;
@mark{@_} = (1) x @_;
keys %mark;
}
...
foreach my $k (sort(uniq keys %hash1, keys %hash2)) {
...
L'exécution donne :
crow% perl donnees_lignes.pl
Unquoted string "uniq" may clash with future reserved word at
donnees_lignes.pl line 165.
...
Si je mets un "&" devant l'appel à uniq ("&uniq" au lieu de "uniq" dans le
foreach), c'est encore pire :
crow% perl donnees_lignes.pl
syntax error at donnees_lignes.pl line 165, near "&uniq keys"
Global symbol "$k" requires explicit package name at donnees_lignes.pl line 166.
Execution of donnees_lignes.pl aborted due to compilation errors.
Pour ne plus avoir d'erreur et que "uniq" soit considéré comme sous programme
et non pas comme une chaîne, il faut que j'écrive le foreach comme cela :
foreach my $k (sort(uniq(keys %hash1, keys %hash2))) {
Cela ne me dérange pas de devoir ecrire ma ligne comme cela. Mais j'aimerais
quand même bien comprendre pourquoi le parseur de perl considère que "uniq"
est une chaîne littérale et non pas un sous-programme quand je veux unitiser
"uniq" en tant qu'opérateur, et pourquoi il faut que je l'utilise
explicitement en tant que fonction (arguments de "uniq" entourés par des
parenthèses) pour que Perl soit content.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jerome Abela
On Feb 15, 9:36 am, Denis Joiret wrote:
foreach my $k (sort(uniq keys %hash1, keys %hash2)) { Unquoted string "uniq" may clash with future reserved word at donnees_lignes.pl line 165.
Le problème ne vient pas de uniq, mais de sort. La syntaxe que tu utilises est ambigue: sort(name @list) peut être interprété de deux façons différentes: - faire un tri sur le résultat de la fonction "name" à laquelle on a passé @list - faire un tri sur @list en utilisant name comme fonction de tri.
Mais je veux bien convenir que le warning est déroutant et ne correspond pas au problème.
Jerome.
On Feb 15, 9:36 am, Denis Joiret <Denis.Joi...@inria.fr> wrote:
foreach my $k (sort(uniq keys %hash1, keys %hash2)) {
Unquoted string "uniq" may clash with future reserved word at
donnees_lignes.pl line 165.
Le problème ne vient pas de uniq, mais de sort. La syntaxe que tu
utilises est ambigue: sort(name @list) peut être interprété de deux
façons différentes:
- faire un tri sur le résultat de la fonction "name" à laquelle on a
passé @list
- faire un tri sur @list en utilisant name comme fonction de tri.
Mais je veux bien convenir que le warning est déroutant et ne
correspond pas au problème.
foreach my $k (sort(uniq keys %hash1, keys %hash2)) { Unquoted string "uniq" may clash with future reserved word at donnees_lignes.pl line 165.
Le problème ne vient pas de uniq, mais de sort. La syntaxe que tu utilises est ambigue: sort(name @list) peut être interprété de deux façons différentes: - faire un tri sur le résultat de la fonction "name" à laquelle on a passé @list - faire un tri sur @list en utilisant name comme fonction de tri.
Mais je veux bien convenir que le warning est déroutant et ne correspond pas au problème.
Jerome.
Denis Joiret
Jerome Abela wrote:
Le problème ne vient pas de uniq, mais de sort. La syntaxe que tu utilises est ambigue: sort(name @list) peut être interprété de deux façons différentes: - faire un tri sur le résultat de la fonction "name" à laquelle on a passé @list - faire un tri sur @list en utilisant name comme fonction de tri.
Du fait que uniq est déclaré comme "sub uniq(@)" et non pas "sub uniq($$)" ou "sub uniq {" (sans prototype), il me semble que cela devrait lever l'ambiguité.
Mais je veux bien convenir que le warning est déroutant et ne correspond pas au problème.
C'est le moins qu'on puisse dire !
Visiblement, la parseur de Perl considère que "uniq" est une fonction à utiliser pour la comparaison du tri, quelle que soit le prototype qu'on lui donne :
crow% perl -we 'sub uniq(@) {$a cmp $b}; ? print join("n", sort (uniq keys %ENV)), "n"' Unquoted string "uniq" may clash with future reserved word at -e line 1. DISPLAY EDITOR GCONF_LOCAL_LOCKS ... XAPPLRESDIR XPID crow%
Jerome.
Denis
Jerome Abela wrote:
Le problème ne vient pas de uniq, mais de sort. La syntaxe que tu
utilises est ambigue: sort(name @list) peut être interprété de deux
façons différentes:
- faire un tri sur le résultat de la fonction "name" à laquelle on a
passé @list
- faire un tri sur @list en utilisant name comme fonction de tri.
Du fait que uniq est déclaré comme "sub uniq(@)" et non pas "sub uniq($$)" ou
"sub uniq {" (sans prototype), il me semble que cela devrait lever l'ambiguité.
Mais je veux bien convenir que le warning est déroutant et ne
correspond pas au problème.
C'est le moins qu'on puisse dire !
Visiblement, la parseur de Perl considère que "uniq" est une fonction à
utiliser pour la comparaison du tri, quelle que soit le prototype qu'on lui
donne :
crow% perl -we 'sub uniq(@) {$a cmp $b};
? print join("n", sort (uniq keys %ENV)), "n"'
Unquoted string "uniq" may clash with future reserved word at -e line 1.
DISPLAY
EDITOR
GCONF_LOCAL_LOCKS
...
XAPPLRESDIR
XPID
crow%
Le problème ne vient pas de uniq, mais de sort. La syntaxe que tu utilises est ambigue: sort(name @list) peut être interprété de deux façons différentes: - faire un tri sur le résultat de la fonction "name" à laquelle on a passé @list - faire un tri sur @list en utilisant name comme fonction de tri.
Du fait que uniq est déclaré comme "sub uniq(@)" et non pas "sub uniq($$)" ou "sub uniq {" (sans prototype), il me semble que cela devrait lever l'ambiguité.
Mais je veux bien convenir que le warning est déroutant et ne correspond pas au problème.
C'est le moins qu'on puisse dire !
Visiblement, la parseur de Perl considère que "uniq" est une fonction à utiliser pour la comparaison du tri, quelle que soit le prototype qu'on lui donne :
crow% perl -we 'sub uniq(@) {$a cmp $b}; ? print join("n", sort (uniq keys %ENV)), "n"' Unquoted string "uniq" may clash with future reserved word at -e line 1. DISPLAY EDITOR GCONF_LOCAL_LOCKS ... XAPPLRESDIR XPID crow%
Jerome.
Denis
john.swilting
Denis Joiret wrote:
Bonjour,
J'ai un comportement curieux avec un sous-programme qui n'est pas reconnu en tant que sous programme par Perl. Voici l'extrait du code concerné :
#!/usr/bin/perl -w use strict; ... sub uniq(@); # declaration ... # conserver un exemplaire unique de chaque element de la liste sub uniq(@) { my %mark; @mark{@_} = (1) x @_; keys %mark; } ... foreach my $k (sort(uniq keys %hash1, keys %hash2)) { ...
L'exécution donne : crow% perl donnees_lignes.pl Unquoted string "uniq" may clash with future reserved word at donnees_lignes.pl line 165. ...
Si je mets un "&" devant l'appel à uniq ("&uniq" au lieu de "uniq" dans le foreach), c'est encore pire :
crow% perl donnees_lignes.pl syntax error at donnees_lignes.pl line 165, near "&uniq keys" Global symbol "$k" requires explicit package name at donnees_lignes.pl line 166. Execution of donnees_lignes.pl aborted due to compilation errors.
Pour ne plus avoir d'erreur et que "uniq" soit considéré comme sous programme et non pas comme une chaîne, il faut que j'écrive le foreach comme cela :
foreach my $k (sort(uniq(keys %hash1, keys %hash2))) {
Cela ne me dérange pas de devoir ecrire ma ligne comme cela. Mais j'aimerais quand même bien comprendre pourquoi le parseur de perl considère que "uniq" est une chaîne littérale et non pas un sous-programme quand je veux unitiser "uniq" en tant qu'opérateur, et pourquoi il faut que je l'utilise explicitement en tant que fonction (arguments de "uniq" entourés par des parenthèses) pour que Perl soit content.
J'ai un comportement curieux avec un sous-programme qui n'est pas reconnu
en tant que sous programme par Perl. Voici l'extrait du code concerné :
#!/usr/bin/perl -w
use strict;
...
sub uniq(@); # declaration
...
# conserver un exemplaire unique de chaque element de la liste
sub uniq(@) {
my %mark;
@mark{@_} = (1) x @_;
keys %mark;
}
...
foreach my $k (sort(uniq keys %hash1, keys %hash2)) {
...
L'exécution donne :
crow% perl donnees_lignes.pl
Unquoted string "uniq" may clash with future reserved word at
donnees_lignes.pl line 165.
...
Si je mets un "&" devant l'appel à uniq ("&uniq" au lieu de "uniq" dans le
foreach), c'est encore pire :
crow% perl donnees_lignes.pl
syntax error at donnees_lignes.pl line 165, near "&uniq keys"
Global symbol "$k" requires explicit package name at donnees_lignes.pl
line 166. Execution of donnees_lignes.pl aborted due to compilation
errors.
Pour ne plus avoir d'erreur et que "uniq" soit considéré comme sous
programme et non pas comme une chaîne, il faut que j'écrive le foreach
comme cela :
foreach my $k (sort(uniq(keys %hash1, keys %hash2))) {
Cela ne me dérange pas de devoir ecrire ma ligne comme cela. Mais
j'aimerais quand même bien comprendre pourquoi le parseur de perl
considère que "uniq" est une chaîne littérale et non pas un sous-programme
quand je veux unitiser "uniq" en tant qu'opérateur, et pourquoi il faut
que je l'utilise explicitement en tant que fonction (arguments de "uniq"
entourés par des parenthèses) pour que Perl soit content.
J'ai un comportement curieux avec un sous-programme qui n'est pas reconnu en tant que sous programme par Perl. Voici l'extrait du code concerné :
#!/usr/bin/perl -w use strict; ... sub uniq(@); # declaration ... # conserver un exemplaire unique de chaque element de la liste sub uniq(@) { my %mark; @mark{@_} = (1) x @_; keys %mark; } ... foreach my $k (sort(uniq keys %hash1, keys %hash2)) { ...
L'exécution donne : crow% perl donnees_lignes.pl Unquoted string "uniq" may clash with future reserved word at donnees_lignes.pl line 165. ...
Si je mets un "&" devant l'appel à uniq ("&uniq" au lieu de "uniq" dans le foreach), c'est encore pire :
crow% perl donnees_lignes.pl syntax error at donnees_lignes.pl line 165, near "&uniq keys" Global symbol "$k" requires explicit package name at donnees_lignes.pl line 166. Execution of donnees_lignes.pl aborted due to compilation errors.
Pour ne plus avoir d'erreur et que "uniq" soit considéré comme sous programme et non pas comme une chaîne, il faut que j'écrive le foreach comme cela :
foreach my $k (sort(uniq(keys %hash1, keys %hash2))) {
Cela ne me dérange pas de devoir ecrire ma ligne comme cela. Mais j'aimerais quand même bien comprendre pourquoi le parseur de perl considère que "uniq" est une chaîne littérale et non pas un sous-programme quand je veux unitiser "uniq" en tant qu'opérateur, et pourquoi il faut que je l'utilise explicitement en tant que fonction (arguments de "uniq" entourés par des parenthèses) pour que Perl soit content.
J'ai un comportement curieux avec un sous-programme qui n'est pas reconnu en tant que sous programme par Perl. Voici l'extrait du code concerné :
#!/usr/bin/perl -w use strict; ... sub uniq(@); # declaration ... # conserver un exemplaire unique de chaque element de la liste sub uniq(@) { my %mark; @mark{@_} = (1) x @_; keys %mark; } ... foreach my $k (sort(uniq keys %hash1, keys %hash2)) { ...
L'exécution donne : crow% perl donnees_lignes.pl Unquoted string "uniq" may clash with future reserved word at donnees_lignes.pl line 165. ...
Si je mets un "&" devant l'appel à uniq ("&uniq" au lieu de "uniq" dans le foreach), c'est encore pire :
crow% perl donnees_lignes.pl syntax error at donnees_lignes.pl line 165, near "&uniq keys" Global symbol "$k" requires explicit package name at donnees_lignes.pl line 166. Execution of donnees_lignes.pl aborted due to compilation errors.
Pour ne plus avoir d'erreur et que "uniq" soit considéré comme sous programme et non pas comme une chaîne, il faut que j'écrive le foreach comme cela :
foreach my $k (sort(uniq(keys %hash1, keys %hash2))) {
Cela ne me dérange pas de devoir ecrire ma ligne comme cela. Mais j'aimerais quand même bien comprendre pourquoi le parseur de perl considère que "uniq" est une chaîne littérale et non pas un sous-programme quand je veux unitiser "uniq" en tant qu'opérateur, et pourquoi il faut que je l'utilise explicitement en tant que fonction (arguments de "uniq" entourés par des parenthèses) pour que Perl soit content.
Email: Phone: +33 1 39 63 53 82 Fax: +33 1 39 63 55 75 moi dans les annees 2002 2003 j ai ecrit des trucs bizarres en perl
perl -el { { slurp(<$lwp = HTTP::Request->new(GET => 'file:/etc/passwd');;> print $_);redo;};}; y manquer un ;
john.swilting wrote:
Denis Joiret wrote:
Bonjour,
J'ai un comportement curieux avec un sous-programme qui n'est pas reconnu
en tant que sous programme par Perl. Voici l'extrait du code concerné :
#!/usr/bin/perl -w
use strict;
...
sub uniq(@); # declaration
...
# conserver un exemplaire unique de chaque element de la liste
sub uniq(@) {
my %mark;
@mark{@_} = (1) x @_;
keys %mark;
}
...
foreach my $k (sort(uniq keys %hash1, keys %hash2)) {
...
L'exécution donne :
crow% perl donnees_lignes.pl
Unquoted string "uniq" may clash with future reserved word at
donnees_lignes.pl line 165.
...
Si je mets un "&" devant l'appel à uniq ("&uniq" au lieu de "uniq" dans
le foreach), c'est encore pire :
crow% perl donnees_lignes.pl
syntax error at donnees_lignes.pl line 165, near "&uniq keys"
Global symbol "$k" requires explicit package name at donnees_lignes.pl
line 166. Execution of donnees_lignes.pl aborted due to compilation
errors.
Pour ne plus avoir d'erreur et que "uniq" soit considéré comme sous
programme et non pas comme une chaîne, il faut que j'écrive le foreach
comme cela :
foreach my $k (sort(uniq(keys %hash1, keys %hash2))) {
Cela ne me dérange pas de devoir ecrire ma ligne comme cela. Mais
j'aimerais quand même bien comprendre pourquoi le parseur de perl
considère que "uniq" est une chaîne littérale et non pas un
sous-programme quand je veux unitiser "uniq" en tant qu'opérateur, et
pourquoi il faut que je l'utilise explicitement en tant que fonction
(arguments de "uniq" entourés par des parenthèses) pour que Perl soit
content.
J'ai un comportement curieux avec un sous-programme qui n'est pas reconnu en tant que sous programme par Perl. Voici l'extrait du code concerné :
#!/usr/bin/perl -w use strict; ... sub uniq(@); # declaration ... # conserver un exemplaire unique de chaque element de la liste sub uniq(@) { my %mark; @mark{@_} = (1) x @_; keys %mark; } ... foreach my $k (sort(uniq keys %hash1, keys %hash2)) { ...
L'exécution donne : crow% perl donnees_lignes.pl Unquoted string "uniq" may clash with future reserved word at donnees_lignes.pl line 165. ...
Si je mets un "&" devant l'appel à uniq ("&uniq" au lieu de "uniq" dans le foreach), c'est encore pire :
crow% perl donnees_lignes.pl syntax error at donnees_lignes.pl line 165, near "&uniq keys" Global symbol "$k" requires explicit package name at donnees_lignes.pl line 166. Execution of donnees_lignes.pl aborted due to compilation errors.
Pour ne plus avoir d'erreur et que "uniq" soit considéré comme sous programme et non pas comme une chaîne, il faut que j'écrive le foreach comme cela :
foreach my $k (sort(uniq(keys %hash1, keys %hash2))) {
Cela ne me dérange pas de devoir ecrire ma ligne comme cela. Mais j'aimerais quand même bien comprendre pourquoi le parseur de perl considère que "uniq" est une chaîne littérale et non pas un sous-programme quand je veux unitiser "uniq" en tant qu'opérateur, et pourquoi il faut que je l'utilise explicitement en tant que fonction (arguments de "uniq" entourés par des parenthèses) pour que Perl soit content.
Email: Phone: +33 1 39 63 53 82 Fax: +33 1 39 63 55 75 moi dans les annees 2002 2003 j ai ecrit des trucs bizarres en perl
perl -el { { slurp(<$lwp = HTTP::Request->new(GET => 'file:/etc/passwd');;> print $_);redo;};}; y manquer un ;
Paul Gaborit
À (at) Thu, 15 Feb 2007 17:25:52 +0100, Denis Joiret écrivait (wrote): [...]
Visiblement, la parseur de Perl considère que "uniq" est une fonction à utiliser pour la comparaison du tri, quelle que soit le prototype qu'on lui donne : [...]
Ce qu'il faut bien comprendre, c'est que la notion de prototype (fourni par l'utilisateur) est très peu utilisée par Perl. Cela fait partie des améliorations en cours...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 15 Feb 2007 17:25:52 +0100,
Denis Joiret <Denis.Joiret@inria.fr> écrivait (wrote):
[...]
Visiblement, la parseur de Perl considère que "uniq" est une fonction
à utiliser pour la comparaison du tri, quelle que soit le prototype
qu'on lui donne :
[...]
Ce qu'il faut bien comprendre, c'est que la notion de prototype
(fourni par l'utilisateur) est très peu utilisée par Perl. Cela fait
partie des améliorations en cours...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Thu, 15 Feb 2007 17:25:52 +0100, Denis Joiret écrivait (wrote): [...]
Visiblement, la parseur de Perl considère que "uniq" est une fonction à utiliser pour la comparaison du tri, quelle que soit le prototype qu'on lui donne : [...]
Ce qu'il faut bien comprendre, c'est que la notion de prototype (fourni par l'utilisateur) est très peu utilisée par Perl. Cela fait partie des améliorations en cours...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>