Thank you, readline works as expected.
However, I still do not understand how <$handle> is not equivalent to <$hash{'handle'}> when they both contain IO::File objects.
| [reply]
[d/l]
[select] |
Simply stated, its because the diamond operator does dual service as both readline and glob. If the value or variable inside looks like a file handle at compile time, then it is interpreted and compiled as readline, if it doesn't, then it is interpreted and compiled as glob. At compile time a hash element is deemed more likely to contain a glob pattern than a filehandle.
As for why, you'd have to ask the author(s), but it is probably a throwback to when perl didn't have lexical filehandles; and it's never been seen as high enough priority to attempt a fix.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Thank you very much! This is the explanation I needed.
I found this in perlop in the I/O Operators section:
"If what's within the angle brackets is neither a filehandle nor a simple scalar variable containing a filehandle name, typeglob, or typeglob reference, it is interpreted as a filename pattern to be globbed, and either a list of filenames or the next filename in the list is returned, depending on context. This distinction is determined on syntactic grounds alone. That means <$x> is always a readline() from an indirect handle, but <$hash{key}> is always a glob(). That's because $x is a simple scalar variable, but $hash{key} is not--it's a hash element. Even <$x > (note the extra space) is treated as glob("$x ") , not readline($x)."
| [reply] |
