BEGIN, INIT etc...

Discussion in 'Perl Misc' started by pgodfrin, Mar 26, 2008.

  1. pgodfrin

    pgodfrin Guest

    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
     
    pgodfrin, Mar 26, 2008
    #1
    1. Advertising

  2. pgodfrin wrote:
    > 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

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Mar 26, 2008
    #2
    1. Advertising

  3. pgodfrin

    pgodfrin Guest

    On Mar 26, 3:49 pm, Gunnar Hjalmarsson <> wrote:
    > pgodfrin wrote:
    > > 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
    >
    > --
    > Gunnar Hjalmarsson
    > Email:http://www.gunnar.cc/cgi-bin/contact.pl


    been there done that. Can we do better?
    pg
     
    pgodfrin, Mar 26, 2008
    #3
  4. pgodfrin

    Guest

    pgodfrin <> wrote:
    > On Mar 26, 3:49 pm, Gunnar Hjalmarsson <> wrote:
    > > pgodfrin wrote:
    > > > 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
    > >

    >
    > 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.
     
    , Mar 26, 2008
    #4
  5. pgodfrin

    pgodfrin Guest

    On Mar 26, 5:37 pm, wrote:
    > pgodfrin <> wrote:
    > > On Mar 26, 3:49 pm, Gunnar Hjalmarsson <> wrote:
    > > > pgodfrin wrote:
    > > > > 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

    >
    > > 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.


    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
     
    pgodfrin, Mar 27, 2008
    #5
  6. pgodfrin

    Uri Guttman Guest

    >>>>> "p" == pgodfrin <> writes:

    p> On Mar 26, 5:37 pm, wrote:
    >> pgodfrin <> wrote:
    >> > On Mar 26, 3:49 pm, Gunnar Hjalmarsson <> wrote:
    >> > > pgodfrin wrote:
    >> > > > Anyone know of a good article that discusses when and why you would
    >> > > > use the BEGIN, UNITCHECK, CHECK, INIT and END code blocks?

    >>

    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

    --
    Uri Guttman ------ -------- 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 ---------
     
    Uri Guttman, Mar 27, 2008
    #6
  7. pgodfrin

    pgodfrin Guest

    On Mar 27, 11:31 am, wrote:
    > On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <>
    > wrote:
    >
    >
    >
    > >>>>>> "p" == pgodfrin <> writes:

    >
    > > p> On Mar 26, 5:37 pm, wrote:
    > > >> pgodfrin <> wrote:
    > > >> > On Mar 26, 3:49 pm, Gunnar Hjalmarsson <> wrote:
    > > >> > > pgodfrin wrote:
    > > >> > > > Anyone know of a good article that discusses when and why you would
    > > >> > > > use the BEGIN, UNITCHECK, CHECK, INIT and END code blocks?

    >
    > > 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

    >
    > 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
     
    pgodfrin, Mar 27, 2008
    #7
  8. pgodfrin

    Uri Guttman Guest

    >>>>> "d" == dummy <> writes:

    d> On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <>
    d> wrote:

    >> 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


    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 ------ -------- 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 ---------
     
    Uri Guttman, Mar 27, 2008
    #8
  9. pgodfrin <> writes:

    > 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.

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
     
    Joost Diepenmaat, Mar 27, 2008
    #9
  10. pgodfrin

    pgodfrin Guest

    On Mar 27, 12:00 pm, Uri Guttman <> wrote:
    > >>>>> "d" == dummy <> writes:

    >
    > d> On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <>
    >
    > d> wrote:
    >
    > >> 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

    >
    > 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 ------ -------- 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, Mar 27, 2008
    #10
  11. pgodfrin

    pgodfrin Guest

    On Mar 27, 12:09 pm, Joost Diepenmaat <> wrote:
    > pgodfrin <> writes:
    > > 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.
    >
    > --
    > Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/


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

    regards,
    pg
     
    pgodfrin, Mar 27, 2008
    #11
  12. pgodfrin

    pgodfrin Guest

    On Mar 27, 12:00 pm, Uri Guttman <> wrote:
    > >>>>> "d" == dummy <> writes:

    >
    > d> On Thu, 27 Mar 2008 03:26:31 GMT, Uri Guttman <>
    >
    > d> wrote:
    >
    > >> 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

    >
    > 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 ------ -------- 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
     
    pgodfrin, Mar 27, 2008
    #12
  13. Joost Diepenmaat wrote:
    > pgodfrin <> writes:
    >> 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.


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

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

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Mar 27, 2008
    #13
  14. pgodfrin

    Bart Lateur Guest

    Joost Diepenmaat wrote:

    >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.

    --
    Bart.
     
    Bart Lateur, Mar 29, 2008
    #14
  15. Bart Lateur <> writes:

    > Joost Diepenmaat wrote:
    >
    >>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.


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

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

    Cheers,
    Joost.

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
     
    Joost Diepenmaat, Mar 29, 2008
    #15
  16. [A complimentary Cc of this posting was sent to
    Bart Lateur
    <>], who wrote in article <>:
    > Joost Diepenmaat wrote:
    >
    > >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.


    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
     
    Ilya Zakharevich, Mar 29, 2008
    #16
  17. pgodfrin

    Ben Morrow Guest

    Quoth Ilya Zakharevich <>:
    > [A complimentary Cc of this posting was sent to
    > Bart Lateur
    > <>], who wrote in article
    > <>:
    > > Joost Diepenmaat wrote:
    > >
    > > >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.

    >
    > 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
     
    Ben Morrow, Mar 29, 2008
    #17
  18. Ben Morrow <> writes:

    > 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?

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
     
    Joost Diepenmaat, Mar 29, 2008
    #18
  19. pgodfrin

    Ben Morrow Guest

    Quoth Joost Diepenmaat <>:
    > Ben Morrow <> writes:
    >
    > > 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?


    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
     
    Ben Morrow, Mar 30, 2008
    #19
  20. Ben Morrow <> writes:

    > Quoth Joost Diepenmaat <>:
    >> Ben Morrow <> writes:
    >>
    >> > 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?

    >
    > 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.

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
     
    Joost Diepenmaat, Mar 30, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tony Cheng
    Replies:
    1
    Views:
    8,218
    Juan T. Llibre
    Feb 24, 2006
  2. Replies:
    1
    Views:
    664
    Jules
    Aug 18, 2005
  3. Kevin Walzer

    Re: PIL (etc etc etc) on OS X

    Kevin Walzer, Aug 1, 2008, in forum: Python
    Replies:
    4
    Views:
    413
    Fredrik Lundh
    Aug 13, 2008
  4. J. Romano

    Should I use BEGIN, CHECK, or INIT?

    J. Romano, Oct 28, 2004, in forum: Perl Misc
    Replies:
    11
    Views:
    213
    John W. Krahn
    Oct 29, 2004
  5. J Krugman

    Q on BEGIN and INIT

    J Krugman, Apr 19, 2005, in forum: Perl Misc
    Replies:
    4
    Views:
    117
    Joe Smith
    Apr 25, 2005
Loading...

Share This Page