For the general construct though, END blocks are the wrong answer. They fire when Perl stops running, not before you exit your subroutine. Instead you probably wanted to use ReleaseAction...

UPDATE
bbfu is right about when the delete should happen. But you could still use ReleaseAction as follows:

$$$fh = ReleaseAction->new(
  sub {unlink $file or die "Cannot unlink $file: $!"}
);
[download]

Actually, tilly, I think that lemmett did want the END blocks to fire when Perl exited, not the subroutine. It would be kind of silly to create a temp file and then proceed to delete it before passing it back to the user. :-)

But I whole-heartedly agree with your suggestion to use File::Temp.

Update (for tilly's update): I like the idea of using a ReleaseAction for unlinking the file as long as the order of execution is OK. That's certainly an interesting way of binding a ReleaseAction to the filehandle (assigning the action reference to the scalar part of the anonymous symbol, right?). I hadn't thought about sticking extra info into the filehandle like that. :-)

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.

It's not "queueing" the END block at run time. The problem is that you're dieing before assigning a value to your variable. So, in effect, you're trying to unlink undef.

You're thinking that the END block shouldn't be called if the subroutine is not called because you've placed the definition inside the subroutine body... That's incorrect. Named subroutines (of which BEGIN and END are just special breeds) are non-lexical. That means they all belong to the package they're declared in, not just the block. The only thing you're accomplishing by declaring your END routine inside the body of new_tmpfile_name is that you're creating a named closure (ie, END keeps a reference to $name, thus keeping it alive longer than it otherwise would be).

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.

A possible solution to do what you seem to be attempting would be to do a string eval. This has an unfortunate side-effect of being a little slow. :-( But it would definately work. :-) Anyway, I hope this bit of explaination helps. Have fun coding!

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.

{
    my @toDelete;
    END {
        for( @toDelete ) {
            unlink $_ or warn "Can't delete $_: $!\n";
        }
    }

    sub new_tmpfile_name {
        # ...
        push @toDelete, $name;
        return $name;
    }
}
[download]

This handles both dieing before any files have been create and dieing after more than one file has been created. Just another way to do it.

You can generalize this:

BEGIN {
  my @coderef;
  END { $_->() for @coderef }
  sub atEND { push @coderef, @_ }
}
...
sub new_tempfile_name {
   ...
   atEND(sub { unlink $name });
   return $name;
}
[download]

Now you can add other things dynamically as well, using one mechanism, just by passing a coderef (usually a closure).

-- Randal L. Schwartz, Perl hacker

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]

An END subroutine is executed as late as possible, 
that is, when the interpreter is being exited, 
even if it is exiting as a result of a die() function. 

In your first test case (where you don't specify a file name), you seem to think that END {} was executed at compile-time. In fact, it's executing at the end of run-time, after you call the die() command. It seems straightforward to me, or am I confused about what you mean?

Update:Ah, thanks as always, tye.

buckaduck

END blocks are queued at compile time. The desire was to queue an END block at run time.

        - tye (but my friends call me "Tye")