> > my $fh = do { local *_ };
>
> That doesn't do anything useful either. My guess is that Perl will
> attempt to stringify the typeglob and put something like
> qw( *package::_ ) into $x.
You sure? Somebody once told me to use
my $fh = do { local *FH };
because local saves the previous value and then as the last statement
in the block returns the blank glob. Seemed wierd, but has always
worked without file collisions.
> If you've got this:
>
> my $fh = do { local *_ };
> open $fh, $file;
>
> then you will be opening the file on a _very_ oddly-named
> handle. Try opening and reading from two files at once in the
> same way!
okay.
File "a":
=========
a1
a2
a3
a4
a5
File "b":
=========
b1
b2
b3
b4
b5
File "tst":
===========
my $f1 = do { local *_ };
my $f2 = do { local *_ };
open $f1, "a" or die $!;
open $f2, "b" or die $!;
print scalar <$f1>;
print scalar <$f2>;
print scalar <$f1>;
print scalar <$f2>;
print scalar <$f1>;
print scalar <$f2>;
print scalar <$f1>;
print scalar <$f2>;
output of command "perl -w tst":
================================
a1
b1
a2
b2
a3
b3
a4
b4
Works fine.
As it was explained to me, the return value from do { local *_ } is the
purely temporary *local* version of the glob, which is stored in the
lexical and used as the filehandle.
However, if I take those lines out of the file and add
my ($f1,$f2);
to declare them, it still works fine. Surprise!
I could swear I tried that before and had an error, but maybe it was
back before we upgraded to 5.6. Anybody out there still got a pre-5.6
Perl to test this on?
The wierd thing is that
my $x = do { local *_ };
print "$x\n";
yields
*main::_
even though the above example proves that the version returned isn't in
conflict. Spooky. :)
> If you have this instead:
> my $fh = do { local *_; \*_ };
> open $fh, $file;
> then you are making $fh a reference to a typeglob, which can
> be used in place of a real typeglob in most places (if not
> everywhere?). However, what this does:
Agreed, though the local() statement returns the glob as well, and a
reference to a glob is more precise, but seldom necessary from what
I've seen.
> open my $fh, $file;
>
> is to autovivify a typeglob for you and set $fh to a reference
> to it, so you get the same effect. In only one line!
Wait a sec -- my() uses lexical scratchpad variables, doesn't it?
I was under the impression that they didn't exactly use typeglobs. You
can't have a lexical format, can you? Or is that also bogus and/or
obsolete info?
> > which can be passed to things that are expecting a filehandle, and
> > NOT a plain scalar.
>
> Well you can pass a scalar, but this is the same sin as using
> symbolic references.
Implicitly, it *is* a symbolic ref, isn't it? Unless the scalar value
has a glob in it?
Both versions of the code I ran above were happy when run under strict,
which I know won't let you use symrefs, which is why I thought it
didn't use to work anyway..... I wrote code that way so it would work
under strict. Now it appears that workaround isn't necessary anymore!
> If you pass a plain scalar as a filehandle you will be
> specifying the filehandle by _name_. Should be safe though, as long
> as it's something obscure like *main::_ :-D
LOL!!! >:0P
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
