BEGIN, INIT etc...

[pgodfrin]

Greetings,
Anyone know of a good article that discusses when and why you would
use the BEGIN, UNITCHECK, CHECK, INIT and END code blocks?

thanks,
pg

 

[Gunnar Hjalmarsson]

Anyone know of a good article that discusses when and why you would
use the BEGIN, UNITCHECK, CHECK, INIT and END code blocks?

perldoc perlmod

 

[pgodfrin]

perldoc perlmod

been there done that. Can we do better?
pg

 

[xhoster]

been there done that. Can we do better?

What parts do you think need improving?

After reading my installed perlmod, I know what BEGIN and END do, and I
know that if I want to do what they do, then I should use the one that does
what I want done. I don't know what more to ask of documentation than
that. For CHECK and INIT, I know that they are used for things I will
probably rarely if ever need to do, but they are in the back of mind,
reminding me to re-read the docs if I ever do decide I might need them.
Again, It isn't clear to me what more is needed.

After reading the 5.10 perlmod, I see that UNITCHECK should be used if
I need something like CHECK but which is run in string evals (and some
other special constructs) unlike CHECK. Maybe it should point out that
UNITCHECK is newer and perhaps existing CHECK and INIT code would be better
done in the newer style as UNITCHECK code.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[pgodfrin]

What parts do you think need improving?

After reading my installed perlmod, I know what BEGIN and END do, and I
know that if I want to do what they do, then I should use the one that does
what I want done. I don't know what more to ask of documentation than
that. For CHECK and INIT, I know that they are used for things I will
probably rarely if ever need to do, but they are in the back of mind,
reminding me to re-read the docs if I ever do decide I might need them.
Again, It isn't clear to me what more is needed.

After reading the 5.10 perlmod, I see that UNITCHECK should be used if
I need something like CHECK but which is run in string evals (and some
other special constructs) unlike CHECK. Maybe it should point out that
UNITCHECK is newer and perhaps existing CHECK and INIT code would be better
done in the newer style as UNITCHECK code.

Xho

--
--------------------http://NewsReader.Com/--------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

Hi Xho,
Sorry - didn't mean to impugn the quality of the docs. All I was
looking for is some sort of article from a trade rag, for instance,
that discussed the utility of those code blocks. You know, maybe some
sort of article where a really good Perl programmer describes how he
(or she ) uses those code blocks in an effective manner.

That's all.

smiles,
pg

 

[Uri Guttman]

p> Sorry - didn't mean to impugn the quality of the docs. All I was
p> looking for is some sort of article from a trade rag, for instance,
p> that discussed the utility of those code blocks. You know, maybe some
p> sort of article where a really good Perl programmer describes how he
p> (or she ) uses those code blocks in an effective manner.

simple answer is to ignore INIT, CHECK and the new UNITCHECK. they are
only for specialized modules and newbies should never need to go near
them. they fall into the rule (which covers symrefs and string eval)
that you shouldn't use them until you know when you don't need them.

BEGIN and END are much more useful and you seem to know about them.

they are commonly used when you need to do something as soon as that
block of code is parsed (BEGIN) or when the program is exiting
(END). and the above rule applies as you don't know when you need or not
need them so don't bother to learn them yet. once you get into perl
deeper you will know more about initialization, compile vs runtime and
destruction. but now you don't know those so ignore BEGIN/END until you
need to learn them.

uri

 

[pgodfrin]

You don't need to know it until you know it? How does that work?
Something like not learning how to drive on ice until after a fatal
skid?

I also would like to learn this topic in advance of need.

OK - I can stay away from INIT, CHECK and UNITCHECK. But your point
about learning about initialization, compile vs runtime and
destruction is pretty much what I'm trying to do - learn about it. So
I will re-iterate my question - is there any information out there -
an article, a book, perl's documentation - that discusses:

How exactly would you use BEGIN and END code blocks for
initialization, compile time, runtime and destruction issues?

I've been using END as a centralized exit point, so that when my code
executes die() or exit() I can still cleanup and do other things. Is
there more to know about that?

I also came across a glitch when using CGI and DBI modules, where some
variables lose scope when the BEGIN code block is completed (which is
clearly alluded to in perlmod). But in plain old Perl I can still
refer to variables assigned in BEGIN in later parts of the code. So
there is a corollary between these code blocks and scope. It would
seem to me that a good discussion about scope (perldoc ???) is in
order too...

thanks,
pg

 

[Uri Guttman]

d> You don't need to know it until you know it? How does that work?
d> Something like not learning how to drive on ice until after a fatal
d> skid?

no, you learn to drive on ice only after you have mastered general
driving and have a need or desire to learn more. most newbies have no
need for BEGIN/END and so don't need to know about them. as they learn
more perl and get to know modules, scoping and compile vs runtime then
those concepts will help them learn how and when to use BEGIN/END. my
point is that they are not needed by newbies and shouldn't be taught as
they will just confuse them.

d> I also would like to learn this topic in advance of need.

do you write modules? do you have subtle initialization or destruction
needs? if not, you don't need to learn them yet. read perlmod more times
and if you don't grasp the concepts then get a good perl book. i can
explain them but it would require a decent sized post or small
article. it makes a good topic and i may do it one day. i already have
seen a need for a definitive article on lists vs arrays and i have been
writing it in my head. but too many things are higher priority for me
now to do that.

uri

 

[Joost Diepenmaat]

OK - I can stay away from INIT, CHECK and UNITCHECK. But your point
about learning about initialization, compile vs runtime and
destruction is pretty much what I'm trying to do - learn about it. So
I will re-iterate my question - is there any information out there -
an article, a book, perl's documentation - that discusses:

How exactly would you use BEGIN and END code blocks for
initialization, compile time, runtime and destruction issues?

BEGIN is there to run code before the later code gets compiled. This is
useful in a few cases, mainly to manually define subroutines & packages
up-front so that the perl compiler knows about them (indirect object
notation relies on this, IIRC). It may also be useful to force some
initialization before use()ing a module that relies on it.

END blocks are useful to "guarantee" that code gets run when the program
ends, even if for example an exception is thrown. Useful for system
resources that may not get freed properly otherwise.

Those two are what you normally need. The others are more esotheric.

INIT, CHECK and UNITCHECK blocks are there to be able to manipulate the
compiled op tree before it gets run and they're IIRC mainly used by the
B backend modules. See for instance, perlguts, B and O.

I've been using END as a centralized exit point, so that when my code
executes die() or exit() I can still cleanup and do other things. Is
there more to know about that?

Not really.

I also came across a glitch when using CGI and DBI modules, where some
variables lose scope when the BEGIN code block is completed (which is
clearly alluded to in perlmod). But in plain old Perl I can still
refer to variables assigned in BEGIN in later parts of the code. So
there is a corollary between these code blocks and scope. It would
seem to me that a good discussion about scope (perldoc ???) is in
order too...

I think you're mistaken, that always happens:

$ perl -Mstrict -w -e'BEGIN { my $f = 1;} print $f'
Global symbol "$f" requires explicit package name at -e line 1.

HTH,
Joost.

 

[pgodfrin]

d> On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <[email protected]>



d> You don't need to know it until you know it? How does that work?
d> Something like not learning how to drive on ice until after a fatal
d> skid?

no, you learn to drive on ice only after you have mastered general
driving and have a need or desire to learn more. most newbies have no
need for BEGIN/END and so don't need to know about them. as they learn
more perl and get to know modules, scoping and compile vs runtime then
those concepts will help them learn how and when to use BEGIN/END. my
point is that they are not needed by newbies and shouldn't be taught as
they will just confuse them.

d> I also would like to learn this topic in advance of need.

do you write modules? do you have subtle initialization or destruction
needs? if not, you don't need to learn them yet. read perlmod more times
and if you don't grasp the concepts then get a good perl book. i can
explain them but it would require a decent sized post or small
article. it makes a good topic and i may do it one day. i already have
seen a need for a definitive article on lists vs arrays and i have been
writing it in my head. but too many things are higher priority for me
now to do that.

uri

--
Uri Guttman ------ (e-mail address removed) -------- http://www.sysarch.com--
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training ---http://perlhunter.com/college.html---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com---------

cool - please let us know when you've written these articles. Where do
those articles get published, btw?
pg

 

[pgodfrin]

BEGIN is there to run code before the later code gets compiled. This is
useful in a few cases, mainly to manually define subroutines & packages
up-front so that the perl compiler knows about them (indirect object
notation relies on this, IIRC). It may also be useful to force some
initialization before use()ing a module that relies on it.

END blocks are useful to "guarantee" that code gets run when the program
ends, even if for example an exception is thrown. Useful for system
resources that may not get freed properly otherwise.

Those two are what you normally need. The others are more esotheric.

INIT, CHECK and UNITCHECK blocks are there to be able to manipulate the
compiled op tree before it gets run and they're IIRC mainly used by the
B backend modules. See for instance, perlguts, B and O.


Not really.


I think you're mistaken, that always happens:

$ perl -Mstrict -w -e'BEGIN { my $f = 1;} print $f'
Global symbol "$f" requires explicit package name at -e line 1.

HTH,
Joost.

Thanks Joost, I will look at the perlguts doc and cleanup my
concepts...

regards,
pg

 

[pgodfrin]

d> On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <[email protected]>



d> You don't need to know it until you know it? How does that work?
d> Something like not learning how to drive on ice until after a fatal
d> skid?

no, you learn to drive on ice only after you have mastered general
driving and have a need or desire to learn more. most newbies have no
need for BEGIN/END and so don't need to know about them. as they learn
more perl and get to know modules, scoping and compile vs runtime then
those concepts will help them learn how and when to use BEGIN/END. my
point is that they are not needed by newbies and shouldn't be taught as
they will just confuse them.

d> I also would like to learn this topic in advance of need.

do you write modules? do you have subtle initialization or destruction
needs? if not, you don't need to learn them yet. read perlmod more times
and if you don't grasp the concepts then get a good perl book. i can
explain them but it would require a decent sized post or small
article. it makes a good topic and i may do it one day. i already have
seen a need for a definitive article on lists vs arrays and i have been
writing it in my head. but too many things are higher priority for me
now to do that.

uri

--
Uri Guttman ------ (e-mail address removed) -------- http://www.sysarch.com--
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training ---http://perlhunter.com/college.html---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com---------

slightly off topic, but - yes I do write modules - only for personal
consumption and very limited needs. Basically 'cause I don't want to
repeat the same exact code in every perl program I write. While not
exactly a newbie to Perl, I probably still qualify as such since most
of my perl code has been very utilitarian - mostly as replacement for
shell scripts. So my needs are very basic as is my experience and
exposure.

So how prevalent is Perl in the commercial world? Do people actually
have full-time jobs writing perl modules? Do people use perl to write
software like Microsoft Office or Quest Software's Toad? Or perhaps
BMC Patrol or CA Univision? What is it mostly used for?

regards,
pg

 

[Gunnar Hjalmarsson]

I think you're mistaken, that always happens:

$ perl -Mstrict -w -e'BEGIN { my $f = 1;} print $f'
Global symbol "$f" requires explicit package name at -e line 1.

So you'd better declare the variable outside the BEGIN block.

$ perl -Mstrict -w -e'my $f; BEGIN {$f=1} print "$f\n"'
1
$

 

[Bart Lateur]

END blocks are useful to "guarantee" that code gets run when the program
ends, even if for example an exception is thrown. Useful for system
resources that may not get freed properly otherwise.

Unfortunately they're still not called on exit and on exec.

 

[Joost Diepenmaat]

Unfortunately they're still not called on exit and on exec.

They are called on exit(), just not on POSIX::_exit

$ perl -w -Mstrict -e'END{ print "END"}; exit'
END

Cheers,
Joost.

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Bart Lateur

Unfortunately they're still not called on exit and on exec.

You mean "Fortunately they are not called on _exit(); do not forget to
never use exec()"?

[END() IS called on exit(). Signal handlers can be installed to die()
on signal, so END() is called on signals.]

Hope this helps,
Ilya

 

[Ben Morrow]

[A complimentary Cc of this posting was sent to
Bart Lateur

Unfortunately they're still not called on exit and on exec.

You mean "Fortunately they are not called on _exit();

Well, no, that's kind-of the point...

do not forget to never use exec()"?

I am confused. How is one (on a fork/exec-based system, or perl's
emulation of such under Win32) supposed to avoid calling exec when
necessary?

[END() IS called on exit(). Signal handlers can be installed to die()
on signal, so END() is called on signals.]

END blocks are not called when a process exits because of the DEFAULT
action of a signal. It is of course possible to fix this by installing
an appropriate signal handler.

Ben

 

[Joost Diepenmaat]

I am confused. How is one (on a fork/exec-based system, or perl's
emulation of such under Win32) supposed to avoid calling exec when
necessary?

By using fork(), ofcourse! Am I missing something?

 

[Ben Morrow]

By using fork(), ofcourse! Am I missing something?

Err... yes? fork creates a clone of the current process, exec changes
which file the current process is executing. Any method of executing an
external program, on Unix, ends up calling exec.

Ben

 

[Joost Diepenmaat]

Err... yes? fork creates a clone of the current process, exec changes
which file the current process is executing. Any method of executing an
external program, on Unix, ends up calling exec.

But for the purposes of END blocks, using fork() before an exec() would
allow the END blocks to run anyway:

# simplified:

END {
# clean up stuff here
# assuming close-on-exec & equivalents are correctly set
}

if (! fork()) { # assumin fork() doesn't fail here.
exec $whatever;
exit;
}
exit;

This is assuming the fork() or exec() themselves won't introduce new
issues.