[pm-h] Perl rename bug?

[Damon Hastings]

I'm guessing they did this as a safety feature; accepting a single container parameter could be bug-prone.  Many other perl functions have similar safeguards (I assume implemented via prototypes.)



On Monday, August 18, 2014 3:41 PM, Perl Developer via Houston <houston at pm.org> wrote:
 

>
>
>Michael,
>
>I see why you might consider this a bug, but I do not believe that it
>is.  Further, I do not believe this is a prototype issue  Consider,
>
>
>bash-4.2$  perl -MO=Terse -e 'my @files=("x", "y"); rename(@files);'
>Not enough arguments for rename at -e line 1, near "@files)"
>-e had compilation errors.
>LISTOP (0x20b8128) leave [1]
>    OP (0x20b7fc8) enter
>    COP (0x20b8170) nextstate
>    BINOP (0x20b81d0) aassign [2]
>        UNOP (0x20b5430) null [147]
>            OP (0x20b53f8) pushmark
>            SVOP (0x20b54b8) const  PV (0x20b6188) "x"
>            SVOP (0x20b5478) const  PV (0x20b60f8) "y"
>        UNOP (0x20b53b0) null [147]
>            OP (0x20b5360) padrange [1]
>            OP (0x20b54f8) padav [1]
>    COP (0x20b8010) nextstate
>    LISTOP (0x20b80a8) rename [3]
>        OP (0x20b8070) null [3]
>        OP (0x20b80f0) padav [1]
>
>bash-4.2$  perl -MO=Terse -e 'my @files=("x", "y"); rename($files[0],
>$files[1]);'
>LISTOP (0x20b9138) leave [1]
>    OP (0x20b8e90) enter
>    COP (0x20b9180) nextstate
>    BINOP (0x20b91e0) aassign [2]
>        UNOP (0x20b6440) null [147]
>            OP (0x20b6408) pushmark
>            SVOP (0x20b64c8) const  PV (0x20b7198) "x"
>            SVOP (0x20b6488) const  PV (0x20b7108) "y"
>        UNOP (0x20b63c0) null [147]
>            OP (0x20b6370) padrange [1]
>            OP (0x20b6508) padav [1]
>    COP (0x20b8ed8) nextstate
>    LISTOP (0x20b8f70) rename [3]
>        OP (0x20b8f38) null [3]
>        UNOP (0x20b9078) null [130]
>            OP (0x20b9100) aelemfast_lex [1]
>            OP (0x20b90c0) null [5]
>        UNOP (0x20b8fb8) null [130]
>            OP (0x20b9040) aelemfast_lex [1]
>            OP (0x20b9000) null [5]
>-e syntax OK
>
>Or even:
>
>bash-4.2$  perl -MO=Terse -e 'my @files=("x", "y"); rename(@files,undef);'
>LISTOP (0x93b138) leave [1]
>    OP (0x93afa0) enter
>    COP (0x93b180) nextstate
>    BINOP (0x93b1e0) aassign [2]
>        UNOP (0x938440) null [147]
>            OP (0x938408) pushmark
>            SVOP (0x9384c8) const  PV (0x939198) "x"
>            SVOP (0x938488) const  PV (0x939108) "y"
>        UNOP (0x9383c0) null [147]
>            OP (0x938370) padrange [1]
>            OP (0x938508) padav [1]
>    COP (0x93afe8) nextstate
>    LISTOP (0x93b080) rename [3]
>        OP (0x93b048) null [3]
>        OP (0x93b100) padav [1]
>        OP (0x93b0c8) undef
>-e syntax OK
>
>Perl sees @files as a container,  rename is looking for 2 arguments,
>whatever they may be.
>
>
>(I doubt my last example will do what you want it to do...)
>
>On Mon, Aug 18, 2014 at 4:03 PM, Michael R. Davis via Houston
><houston at pm.org> wrote:
>> Perl Mongers,
>> Is this a bug in rename?  I googled but did not find anything off the top.
>>
>> $ perl -e 'my @files=("x", "y"); rename(@files);'
>> Not enough arguments for rename at -e line 1, near "@files)"
>> Execution of -e aborted due to compilation errors.
>>
>> But this works fine.
>>
>> $ perl -e 'my @files=("x", "y"); rename($files[0], $files[1]);'
>>
>> Mike
>>
>> mrdvt92
>>
>> $ perl -v
>> This is perl, v5.10.0 built for x86_64-linux-thread-multi
>> Copyright 1987-2007, Larry Wall
>>
>> _______________________________________________
>> Houston mailing list
>> Houston at pm.org
>> http://mail.pm.org/mailman/listinfo/houston
>> Website: http://houston.pm.org/
>
>
>
>-- 
>Best Regards,
>[Joseph] Christian Werner Sr
>C 360.920.7183
>H 757.304.0502
>
>_______________________________________________
>Houston mailing list
>Houston at pm.org
>http://mail.pm.org/mailman/listinfo/houston
>Website: http://houston.pm.org/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/houston/attachments/20140818/c0959521/attachment-0002.html>