I, certainly, always use lexical filehandles, and only noticed what follows, while poking with a stick at couple lines of code trying quick examples for foreach $1
The open explicitly states:
If FILEHANDLE is an undefined scalar variable (or array or hash element), a new filehandle is autovivified, meaning that the variable is assigned a reference to a newly allocated anonymous filehandle. Otherwise if FILEHANDLE is an expression, its value is the real filehandle. (This is considered a symbolic reference, so use strict "refs" should not be in effect.)
The print only says:
FILEHANDLE may be a scalar variable containing the name of or a reference to the filehandle, thus introducing one level of indirection.
And it also dies under use strict "refs" in case of "name".
Some of other built-ins seem to be quite tolerant (but why?) to expression producing a "symbolic reference"; what's worse is that their descriptions use what I'd call "vague" language.
close: FILEHANDLE may be an expression whose value can be used as an indirect filehandle, usually the real filehandle name or an autovivified handle.
(please, what's "unusual"?)
seek: FILEHANDLE may be an expression whose value gives the name of the filehandle
(that's clear enough)
readline: Reads from the filehandle whose typeglob is contained in EXPR
(actually, no -- EXPR also may give a name (and use strict "refs" doesn't matter). Or wait... Do they mean EXPR "contains typeglob" if it resolves to its name? English is not my mother tongue and I'm confused... H-mm)
read skips discussing what FILHANDLE may be alltogether... And so on.
Tangentially related, e.g. closedir dies angrily if expression resolves to plain string. Somewhat un-perlish, not "fail silently".
In reply to (Some) inconsistencies with IO built-ins, their documentation and filehandle names ("symbolic references") by vr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |