Re^4: unquoted string error??!!

If you willfully ignore all warnings and meaningful return values, then of course you should expect to have inherently buggy code:

% perl -Mautodie /tmp/buggy
Name "main::OUTPUT_FILE" used only once: possible typo at /tmp/buggy l
+ine 16.
Can't close filehandle 'OUTPUT_FH': 'Bad file descriptor' at /tmp/bugg
+y line 19
[download]

Did you somehow expect something else? Perl gives you the tools to diagnose and debug such buggery. Do not blame Perl if you ignore its prudent advice.

PROOF: Lexicals Filehandles Aren’t

I have a problem with this whole “lexical filehandle” folderol. That problem is that the name does not fit the thing.

This is not a lexical filehandle:

use vars qw($fh);
undef $fh;
open($fh, "> /tmp/data.$$")
    || die "can't open /tmp/data.$$: $!");
print $fh "I am so NOT a lexical filehandle.\n";
close($fh)
    || die "can't close /tmp/data.$$: $!";
[download]

This is a lexical filehandle:

my $fh = *STDOUT;
print $fh "I am SO TOO lexical filehandle.\n";
[download]

I therefore submit that the thing you are talking about is not “lexical filehandles”, and to call them what they are not is to risk introduction of bugs in one’s mental model.

I believe what you are referring to is not “lexical handles”, but instead autovivified anonymous handles, which may — or may not —happen to be stored in lexical variables.

Comment on Re^4: unquoted string error??!! Select or Download Code

Replies are listed 'Best First'.
Re^5: unquoted string error??!! by runrig (Abbot) on May 04, 2011 at 18:05 UTC
Ok, you're right, there is a warning here. I think though that the actual code closed another handle that was already closed from some other function. And if there was a warning, it would have been in a log file with lots of other output (though probably at the top of the file). And autodie may caught it also, but we're using 5.8.8, so autodie is not in core, but since we tend to trap and email errors, that would probably require eval, and if you think I have trouble getting people to use lexical handles (or AAH's which happen to be stored in lexical variables...), just watch me try to get anyone to use eval. So sure, there are lot's of ways to catch this bug, but I think the simplest way to catch it dead in it's tracks at 'compile' time would have been to use a lexical handle. OR, say the subroutine had 2 handles, and you closed one of them twice. The other would be closed when the sub exited, so you'd still have 'bad' code, but no bug.	[reply]
Re^6: unquoted string error??!! by JavaFan (Canon) on May 05, 2011 at 11:16 UTC
And if there was a warning, it would have been in a log file It's a frigging compile time warning! You mean, you're even skipping the "see whether it compiles" step before shipping? OR, say the subroutine had 2 handles, and you closed one of them twice. The other would be closed when the sub exited, so you'd still have 'bad' code, but no bug. So, your claim is that you ought to be using "lexical filehandles" because if you are in the habit of ignoring warnings (including compile time warnings), ignoring return values from `close` because there may be a situation where Perl does the thing you wanted it to do at the right time? Sounds like a pretty weak argument to me.	[reply] [d/l]
Re^6: unquoted string error??!! by tchrist (Pilgrim) on May 04, 2011 at 18:16 UTC
If you don’t check return values, don’t blame Perl for errors in your code. Same with C. Also, if you close a file twice, then that is also an error. You should have checked the return value from `close` both times — and every time. Who closes files without checking to see whether it worked? That’s just begging for catastrophe.	[reply] [d/l]
Re^7: unquoted string error??!! by runrig (Abbot) on May 04, 2011 at 22:23 UTC
Well, I never said this (the original code anyway) was my code. And at least one other person sometimes closes files without checking the return value :-)	[reply]
Re^8: unquoted string error??!! by tchrist (Pilgrim) on May 04, 2011 at 22:58 UTC
Re^9: unquoted string error??!! by Anonymous Monk on May 04, 2011 at 23:44 UTC