Re^4: Scoping question - will file handle be closed? ("global")

[anonymized user 468275]

Yes I know what 'local' does, but this topic has nothing to do with the use of local. Please refrain from confusing people at a lower level than yourself, who need to know, for example, how global variables work!

You could have said, for example, 'Although globals including filehandles do not go out of scope, this behaviour can be avoided using the local keyword' (and then put your example).

Update: in your second example your variable is specifically of lexical scope, but there is an underlying global that gets assigned to $fh which doesn't go out of scope. OK looks like there's a trick going on here. $fh becomes \*{'::$fh'} which is a global that depends on a local. So although the filehandle isn't closed, it does become lexically inaccessible.

[tye]

Update: in your second example your variable is specifically of lexical scope, but there is an underlying global that gets assigned to $fh which doesn't go out of scope.

No, you are wrong. But you seem doggedly unable to learn on this point so I won't bother trying further to get you to.

[anonymized user 468275]

Technically I was right but it looks like the global depends on $fh and so becomes lexically inaccessible, although that isn't quite the same as being closed. So yes, I have learned something here, thanks.

[Corion]

A "global" cannot become "lexically inaccessible". That's what "global" means.

I think your basic misconception comes from the good old days of Perl 4 and Perl 5.005, where Perl did not have lexical filehandles. The global variables holding the data on filehandles were more or less identical to a string. But this has changed with Perl 5.6.1, which was released in 2003 I think.

[tye]

although that isn't quite the same as being closed

So you still refuse to learn this. The code demonstrates that the handle is actually closed, despite your persistent denials. Becoming lexically inaccessible doesn't cause impacts on external programs. The output lines appearing in the given order:

ls: write error
End

shows that the handle is indeed closed (causing bin/ls to complain) before the next statement of Perl is executed.

The actual mechanism is that the lexical file handle contains a reference to a GLOB, which is the same data structure that Perl uses for global variables. But this GLOB is not a global variable because it isn't stored in a symbol table. Which means that when the lexical goes out of scope (and has no references), the lexical is destroyed which removes the last reference to the GLOB which then destroys the GLOB which also closes the file handle.

There is no global variable involved (because to be a global variable it has to have global scope; that is the definition of a global variable). And it does get destroyed and it does get closed (it can be destroyed because it isn't a global variable).