Re: Taking control back once Interactive script completes

No need to fork and no need to exec. system will do nicely.

$ cat bashout.pl 
#!/usr/bin/env perl 
use strict;
use warnings;

print "This is perl\n";
system ('bash');
print "This is perl, again\n";
$ ./bashout.pl
This is perl
$ echo $SHELL
/bin/bash
$ exit
exit
This is perl, again
$
[download]

Comment on Re: Taking control back once Interactive script completes Download Code

Replies are listed 'Best First'.

Re^2: Taking control back once Interactive script completes
by afoken (Chancellor) on Feb 27, 2020 at 20:00 UTC

No need to fork and no need to exec. system will do nicely.

Behind the scenes, system() combines fork() and exec() with the missing part of the story: wait resp. waitpid waiting for the child process in the parent process. Or, at least it does so on Unix-like systems. What happens on the children of CP/M (DOS, Windows, OS/2) is a different story ...

But on Unix and friends, all that's really missing is wait():

# Lots of random code #
unless (fork()) {
   exec "inter.exe", "--active";
}
wait();
# Some remaining code
[download]

To make that a little more robust, check if fork() returns undef. It may happen from time to time, RTFM. Also, you may want to keep the PID of the child process in the parent process and explicitly wait for that process to return:

# Lots of random code #
my $pid=fork() // die "Can't fork: $!";
# on ancient perls: my $pid=fork(); defined($pid) or die "Can't fork: 
+$!";
unless ($pid) {
   exec "inter.exe", "--active";
}
waitpid($pid,0);
# Some remaining code
[download]

Alexander

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

[reply]
[d/l]
[select]


Pathologically Eclectic Rubbish Lister
	PerlMonks