Sure!

Completely cover all my needs! Just followed shell-script functionality and did not guess about the END{}

Thanks!

Note that END blocks are executed in the reverse order they are "registered". If you want or need your END block to run last, you need to put it before any use directives (though should be safe to put it after strict and warnings).

use strict;
use warnings;

my $exit_normally = 0;
sub exit_handler;
END { exit_handler; }

# other use directives

sub exit_handler { ... }

...

$exit_normally = 1;
__END__
[download]

update

From my understanding are handlers %SIG supposed to process external (OS specific) signals send from a kill command to the process, maybe with the only exception of warn and die which are not signals but internal hooks.

see also perlipc#Signals

I couldn't find any mention of the possibility to intercept exit() with a sighandler

But this "trapping exit() calls with %SIG" explicitly shows how to execute code in an END block after exit .

Sorry for uncomfortability of < pre >, but on < p > I do not like big intervls; without anything - I hate spagety lines...

Yes, the END{} completely fine with me.

Thanks!

> Sorry for uncomfortability of < pre >, but on < p > I do not like big intervls; without anything - I hate spagety lines...

And the monastery hates <pre> tags and you are free to use <br> tags ... :)

please see Markup in the Monastery

Tags You Should NOT Use

At first blush, the <pre> ...</pre> pair may look like an alternative to code tags... BUT DON'T USE IT HERE chiefly because <pre>...</pre> tags will not persuade the Monastery to provide a download link for the contents of the <pre> ... and while it is now supposed to wrap lines that are too long for the viewer's browser window, there are ways Monks could use CSS that would defeat that. So, please. don't use <pre>...</pre> .

If you want I wrote a "wiki" add on for the monastery in JS facilitating the creation of posts (especially on mobiles)

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}

Of course, going to the next level, you can't switch "exit" handlers midstream, and you can't unregister END{} blocks, AFAIK. I suppose there would have to be only one END{} block, with a dynamic call table for subs, and the call table gets changed as needed during the program execution. (Maybe this is proper class material, with methods to mangle the call table.)

you can't switch "exit" handlers midstream, and you can't unregister END{} blocks,

But you can enable or disable code in the END blocks by using flag variables:

>cat demo.pl
#!/usr/bin/perl

use v5.12;
use warnings;

our $endFlag;

END {
        if ($endFlag) {
                say "End flag is set, have to so some cleanup";
                say "Wash, rinse, repeat" for 1..5;
        } else {
                say "Nothing to do";
        }
}

$endFlag = $ARGV[0];

say "How will this end?";
>perl demo.pl 0
How will this end?
Nothing to do
>perl demo.pl 1
How will this end?
End flag is set, have to so some cleanup
Wash, rinse, repeat
Wash, rinse, repeat
Wash, rinse, repeat
Wash, rinse, repeat
Wash, rinse, repeat
>
[download]

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Thanks; th END{} works; just did not guessed!

And, sure, conditional execution in END{} useful! (Almost the same: for %SIG change a line of code needed; so, for a exit_condition, also, just a line!)