update: scratch that, I misread your post.
Well no, BEGIN blocks are executed first?
qwurx [shmem] ~ > echo foo > foo; echo bar >> foo;
qwurx [shmem] ~ > perl -ple 'BEGIN { close ARGV } print' foo
foo
bar
Had the filehandle ARGV ever been open before or in the BEGIN block, it is re-opened after the BEGIN block.
But I would guess ARGV isn't open in the BEGIN block. Makes more sense to me, anyways. But... perhaps
perl -ple 'BEGIN{close ARGV; binmode ARGV} s/foo/bar'
will do.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply]
[d/l]
[select] |
You'd have to be able to call binmode between the implicit file open, and the reading of the first line. And you just can't interject code there. Yes you can. eof with no parens and no parameters starts the ARGV magic but doesn't read any lines.
| [reply] |
After my previous reply, I found the time and facilities and ran a quick test and found two mistakes in your suggestion. First, it is eof() (with parens) not eof without parens that triggers ARGV magic.
Second, as I suspected, eof() does read ahead:
% perl -del existingFile.txt
DB<1> x eof()
0 ''
DB<2> x sysseek(*ARGV,0,1)
0 4096
DB<3>
So, if on a platform where binmode mattered, binmode() would not have been in effect for the first 4096 (resulting) bytes of the file. (But note that you don't need such a platform to perform this test.) Part of the problem here is that the impact of binmode is handled by the underlying I/O layers, not by Perl, so the bytes pre-read have already passed through the layer where binmode would be applied (but wasn't).
If there is some way to get eof without parens to trigger an ARGV-magic implicit open, then I couldn't figure it out and so didn't test it. So please describe it in more detail.
| [reply]
[d/l]
[select] |
I'll believe that when I see test code to demonstrate it. My recollection is that eof reads ahead to see whether you are at EOF rather than just returning whether Perl already knew that you were at EOF.
I can see eof allowing code to run just before an implicit close / open, but I'd be surprised to find eof not causing an implicit read() after it caused an implicit open().
Sorry, I'm not in a position to test it myself at the moment.
| [reply] |
