Is $reg_out global? If yes, could fileevent be cancelling the current bind and binding to new shell-out? Similar problem of "freezing" was solved here: Perl::TK - fileevent and script execution theory

BTW, you certainly don't want exec because it replaces the current perl process and once finished, you program will exit.

Outside the Tk realm, if you want to run a background process you could fork first and then spawn/shellout. Like:

my $pid = fork() // die "fork: $!";
if( $pid ){
    print "forked: i am shelling out\n";
    spawn();
    print "after shelling out.\n";
}
print "I am now waiting for background process.\n";
waitpid $pid, 0;
print "done.\n";

sub spawn {
    my $pid = open(my $xx, "sleep 1 2>&1|") or die "fork: $!";
    print "implicitly waiting for child...\n";
    # close($xx);
}
[download]

Also, I don't know what side-effects fileevent has on the above code, but usually when forking out to an external command you must wait for it to finish. Essentially, close($reg_out) acts as a waitpid $status, 0;. But if you don't, then perl will implicitly wait for it. If the code you posted is a sub, it will not exit until $cmd is dead (again, I don't know how fileevent interferes with this if at all).

So, something like this:

print "before spawn\n";
spawn();
print "after spawn\n";

sub spawn {
    my $pid = open(my $xx, "sleep 3 2>&1|") or die "fork: $!";
    print "implicitly waiting for child...\n";
    # the proper way to wait for the command to exit:
    # close($xx);
}

# output:

before spawn
implicitly waiting for child... # sleep...
after spawn
[download]

UPDATE: exec on the other hand is used in a trick where the program forks using open(my $xx, '|-'); and at the child branch the external command is spawned using exec (which offers finer control over open if one wants to avoid the shell). But that's different to calling exec() in your normal program flow (as an alternative to system()) as it will kill your program.

bw, bliako