in reply to Re^4: How 'bout an argv pragma?
in thread How 'bout an argv pragma?

I would be much more surprised to have localizing @ARGV affect *ARGV{IO}, but I can see how you could feel otherwise. But I'm not sure this kind of dwimmery is effective; there is a similar, documented dwim when you localize $., but I think that's so little known as to be almost pointless.

Your test passes for me on perl, v5.8.8 built for i486-linux-gnu-thread-multi; I'll try to experiment with other versions when I have more time.

Replies are listed 'Best First'.
Re^6: How 'bout an argv pragma?
by blazar (Canon) on May 29, 2008 at 16:57 UTC

    I personally believe that localizing @ARGV only without the rest would be of little to no utility at all, and intuitively it should do what I thought. Well, at least Juerd thought so, too. (Thanks to BrowserUk, who let me know.) Further, people can start to play with (most common) predefined variables and local early, but learn about typeglobs only much later. Actually I think that $Larry now believes they were not a nice idea at all, and that's why they are going away in Perl 6; more precisely here's what he said:

    Nope, typeglobs are dead, dead, dead, dead, and dead, not necessariy in that order.
    --
    If you can't understand the incipit, then please check the IPB Campaign.
      <beating on a dead horse ?>

      I feel typeglobs are a red herring here; the point is that you want to localize both the @ARGV array and the *ARGV{IO} filehandle and those are separate actions (that local *ARGV happens to do both of). I don't see Juerd thinking the two should be tied together in that thread (other than in his initial post not recognizing the possibility of <> being in use in an outer context).

      I've localized @ARGV when calling Getopt::Long::GetOptions before. @ARGV's implicit use by <ARGV> is only a small part of what it does.

      </beating on a dead horse ?>
        the point is that you want to localize both the @ARGV array and the *ARGV{IO} filehandle and those are separate actions (that local *ARGV happens to do both of)

        The chief state you need to save is the list of filenames (@ARGV)... oh, and the magic filehandle. That is, the two pieces of state information you need to save are @ARGV and the magic filehandle... oh, and, the current file name ($ARGV). Three! The three pieces of state information you need to save are @ARGV, $ARGV, the magic file handle and... Four! Er. Among the chief pieces of state information that need to be preserved are such diverse elements as ...

        It's so silly of you to think that I'd do local( *ARGV ) to save just two of the slots!

        Perhaps $^I should become an alias for $ARGV{'inplace'} so we can have more controls for how <> behaves, such as making the default for $ARGV{'interp'} be "filenames" not "magical" so <> after echo data > '|echo Perl is my bitch' just reads "data\n" in? Then we'd have even more reason for local(*ARGV) !

        - tye        

        I don't see Juerd thinking the two should be tied together in that thread (other than in his initial post not recognizing the possibility of <> being in use in an outer context).

        That is what I meant. I didn't recognize it at a first glance, either. And I'm sure most people who are not Perl gurus would, and even some who are too.

        I've localized @ARGV when calling Getopt::Long::GetOptions before. @ARGV's implicit use by <ARGV> is only a small part of what it does.

        Good point but I beg to differ: @ARGV's implicit use by <ARGV> is certainly not the only thing it does, but perhaps the biggest part of it. Another one that springs to mind is shift and pop defaulting to it outside of a sub. But the fact Getopt::* modules use it does not constitute something "it does" since it doesn't belong to the sematics of the language, while those other things do!

        --
        If you can't understand the incipit, then please check the IPB Campaign.