Okay, here's where the self-flagellation part of this whole monastery theme comes in.

bbfu, you gave me the piece I needed to see the light with:

A corollary to this is the fact that if you were to call new_tmpfile_name multiple times, END would still only be called once and only the first temp file unlinked. I suspect this is not what you mean to happen.

There's no contradiction between how I think END block queuing works once I realized that the program isn't working correctly. There are a lot of temp files not getting deleted. Why did I think it was working? All of my testing (using just a single temp file) worked great. Makes me think of this joke.

Not sure why I didn't trigger to the END-block-in-a-function weirdness when I originally wrote it. Hopefully it was just late!!

tilly thanks for the pointers about File::Temp and ReleaseAction. File::Temp I knew about and purposefully chose not to use. For this application I'm not in danger of a race condition nor do I need the portability or additional functionality. Because of the specific systems this is deployed on, getting the module deployed on all of them is a lot more of a hassle than it should be. ReleaseAction looks very cool and I'll be pulling it down and playing with it soon.

bbfu thanks for triggering the flash of insight. I thought about the eval approach but decided against it.

tye I implemented something almost identical to this shortly after I ran into the problem. merlyn's got an interesting take on it that I'll keep in mind, but I don't need the general case this time around.

buckaduck The conflict I thought I saw with the documentation was with a chart at the end of chapter 18 in the Camel v3. Even though I knew END blocks should all get queued at compile time, when I thought the code was working it looked like they were getting queued at both compile and run time.

Again, thanks for the help. I thought this might be another case of perl acting a little too smart. Kind of like when Dominus pointed out that these two lines do the same thing:

print "\L\uTeStInG\E.\n";
print "\u\LTeStInG\E.\n";

[download]

In reply to Re: END blocks created at run time? by lemmett
in thread END blocks created at run time? by lemmett

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.