crazyinsomniac said

>> So I test it out, like i do everything, and i do:  perl -e"%a=( 1..10, 11..20 );print keys %a" and I get no output.

Well, when I test in on my one and only Perl (5.6.1 build 628 on Win2k), I get this

H:\>perl -e"%a=( 1..10, 11..20 );print keys %a"
137159117319115
[download]

or in a more readable version

H:\>perl -e"%a=( 1..10, 11..20 );print qq{@{[keys %a]}}"
13 7 15 9 1 17 3 19 11 5
[download]

both of which look good to me.

crazyinsomniac continued

>> So now I says to me, this must be a bug, and to confirm, i try:

perl -MData::Dumper -e "%a= 1 .. 10, 2 .. 11 ;print Dumper \%a"
[download]

which yields nada, and then ...

Me again, when I test it, I get this - as expected.

H:\>perl -MData::Dumper -e "%a= 1 .. 10, 2 .. 11 ;print Dumper \%a"
$VAR1 = {
          '7' => 8,
          '9' => 10,
          '1' => 2,
          '3' => 4,
          '5' => 6
        };
[download]

Seems to work nicely. The % character that japhy mentioned is tucked inside the double quotes and is seen by Perl, not the cmd shell.

So where is the problem? Did I miss something here?

I am all for bashing the cmd shell (pun intended) when justified, but here I cannot confirm the problem.

Can you help me out on this, crazyinsomniac ?

Rudif

Update Could somemonk please set me straight on the operator precedence in the second example above?

I think that the assignment binds 1..10 to %a, whereas 2..11 has no effect other than being the return value from the comma operator, which is thrown away. Is this correct?