BEGIN, INIT etc...

[Ben Morrow]

But for the purposes of END blocks, using fork() before an exec() would
allow the END blocks to run anyway:

Sorry, I misunderstood you. Yes, that will work, of course.

# simplified:

END {
# clean up stuff here
# assuming close-on-exec & equivalents are correctly set
}

if (! fork()) { # assumin fork() doesn't fail here.
exec $whatever;
exit;

You need POSIX::_exit here, or the END blocks get run twice (once for
each process).

}
exit;

You probably want to wait here before exitting, as otherwise the execed
process is orphaned, and your parent gets SIGCHLD early. You probably
also want to set up signal handlers to pass signals along, etc... see
the source for the shell of your choice . Or you could just use
system, which does all that for you.

Ben

 

[Joost Diepenmaat]

You need POSIX::_exit here, or the END blocks get run twice (once for
each process).

Sorry, that's my mistake: exec() never returns, unless it fails, and I
tried to disregard every complication to make the point.

You probably want to wait here before exitting, as otherwise the execed
process is orphaned, and your parent gets SIGCHLD early. You probably
also want to set up signal handlers to pass signals along, etc... see
the source for the shell of your choice . Or you could just use
system, which does all that for you.

Sure, this is just the extremely simplified version

 

[szr]

Sorry, I misunderstood you. Yes, that will work, of course.


You need POSIX::_exit here, or the END blocks get run twice (once for
each process).

This could actually desirable in some cases, such as when you need to
free/clean-up in each child? (Albiet it would probably be done
differently.)

 

[Joost Diepenmaat]

This could actually desirable in some cases, such as when you need to
free/clean-up in each child? (Albiet it would probably be done
differently.)

Normally, the exec() would succeed, and the exit() would not be called
at all. I tried to ignore all error handling, and that exit() statement
just slipped through.

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Ben Morrow

I am confused. How is one (on a fork/exec-based system, or perl's
emulation of such under Win32) supposed to avoid calling exec when
necessary?

The situations when it is *necessary* to call exec() do exist. But
they are extremely rare. fork() is useful slightly more often; but
again, these situations are in no way frequent.

[The introduction of fork()/exec() mess is one of the major weaknesses
of *nix. Fortunately, Perl API makes it practically never needed.]

Yours,
Ilya

 

[Peter J. Holzer]

So how prevalent is Perl in the commercial world? Do people actually
have full-time jobs writing perl modules?
Yes.

Do people use perl to write software like Microsoft Office

I doubt it.

or Quest Software's Toad? Or perhaps BMC Patrol or CA Univision?

These three are probably closer. (In fact I've been considering to write
"something like Toad" in Perl - it could save me a lot of time, but
unfortunately I first need to find the time to write it).

I doubt you'll find much "shrink-wrapped" software written in perl -
companies which sell shrink-wrapped software don't like to give away
their source code (the customer might see how grotty it is ).

What is it mostly used for?

Lots of "backoffice" stuff: Converting data, producing reports, printing
bills. Anything which has to gather and mangle lots of data from files
or databases.
Tools: Everything you need "in-house" to make some job easier and which
you can't buy off the shelf.
Web-Applications: From small cgi scripts to really large applications.
Analysis: From Server-Logs to the human genome.

hp

 

[pgodfrin]

I doubt it.


These three are probably closer. (In fact I've been considering to write
"something like Toad" in Perl - it could save me a lot of time, but
unfortunately I first need to find the time to write it).

I doubt you'll find much "shrink-wrapped" software written in perl -
companies which sell shrink-wrapped software don't like to give away
their source code (the customer might see how grotty it is ).


Lots of "backoffice" stuff: Converting data, producing reports, printing
bills. Anything which has to gather and mangle lots of data from files
or databases.
Tools: Everything you need "in-house" to make some job easier and which
you can't buy off the shelf.
Web-Applications: From small cgi scripts to really large applications.
Analysis: From Server-Logs to the human genome.

hp

Hi Peter,
Makes sense - all I've ever use Perl for is the same sort of back-
office kind of work. Mostly instead of C or COBOL. In the mainframe
world I used to use SAS a lot, instead of - well - COBOL...

cheers,
pg