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

So you think localizing @ARGV should also localize the (potentially open) ARGV filehandle too?

I personally believe that based on the principle of least surprise, I would indeed say so. Perl does magic worse than that already, and otherwise a localised @ARGV would be of little utility since one would want to use the above described technique (referring to your sub) as a cheap shortcut to

sub collect { join '', map { open my $fh, '<', $_ or warn "Can't open `$_': $!\n"; <$fh>; } @_; }

(But for the 2-args implicit openedness, of course.)

What exactly did you try? Localizing *ARGV worked for me exactly as I would have thought:

It doesn't work for me:

picard:~/tmp [11:26:38]$ perl -v | head -n 2 This is perl, v5.10.0 built for i486-linux-gnu-thread-multi picard:~/tmp [11:26:42]$ cat ../domk.pl #!/usr/bin/perl use strict; use warnings; while (<>) { chomp; print "huzzah:".collect( $_ )."!\n"; } sub collect { local *ARGV; @ARGV = @_; join '', <>; } __END__ picard:~/tmp [11:26:55]$ ls file? | ../domk.pl Can't open file1: No such file or directory at ../domk.pl line 14. huzzah:! Can't open file2: No such file or directory at ../domk.pl line 14. huzzah:! Can't open : No such file or directory at ../domk.pl line 14. huzzah:!

But even if it did "work", as it did with you and kyle, it wouldn't be much dwimmy: in fact your output is not the same one would have got out of using the "expanded" sub above. The following example won't work on my box either, but you could try it:

#!/usr/bin/perl use strict; use warnings; use Test::More 'no_plan'; sub dargv { local *ARGV; @ARGV = @_; <>; } sub dopen { map { open my $fh, '<', $_ or warn "Can't open `$_': $!\n"; <$fh>; } @_; } while (<>) { chomp; is_deeply [dargv $_], [dopen $_] => $_; } __END__

Update: dopen has issues; this was discussed in another thread.

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

Replies are listed 'Best First'.
Re^5: How 'bout an argv pragma?
by ysth (Canon) on May 29, 2008 at 01:53 UTC
    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.

      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 ?>