[Python-Dev] Portable "spawn" module for core?

Greg Ward gward@cnri.reston.va.us
Mon, 30 Aug 1999 15:31:55 -0400


On 30 August 1999, Skip Montanaro said:
> 
>     Greg> it recently occured to me that the 'spawn' module I wrote for the
>     Greg> Distutils (and which Perry Stoll extended to handle NT), could fit
>     Greg> nicely in the core library.
> 
> How's spawn.spawn semantically different from the Windows-dependent
> os.spawn?

My understanding (purely from reading Perry's code!) is that the Windows
spawnv() and spawnve() calls require the full path of the executable,
and there is no spawnvp().  Hence, the bulk of Perry's '_spawn_nt()'
function is code to search the system path if the 'search_path' flag is
true.

In '_spawn_posix()', I just use either 'execv()' or 'execvp()'
for this.  The bulk of my code is the complicated dance required to
wait for a fork'ed child process to finish.

> How are stdout/stdin/stderr connected to the child process - just 
> like fork+exec or something slightly higher level like os.popen?

Just like fork 'n exec -- '_spawn_posix()' is just a front end to fork
and exec (either execv or execvp).

In a previous life, I *did* implement a spawning module for a certain
other popular scripting language that handles redirection and capturing
(backticks in the shell and that other scripting language).  It was a
lot of fun, but pretty hairy.  Took three attempts gradually developed
over two years to get it right in the end.  In fact, it does all the
easy stuff that a Unix shell does in spawning commands, ie. search the
path, fork 'n exec, and redirection and capturing.  Doesn't handle the
tricky stuff, ie. pipelines and job control.

The documentation for this module is 22 pages long; the code is 600+
lines of somewhat tricky Perl (1300 lines if you leave in comments and
blank lines).  That's why the Distutils spawn module doesn't do anything
with std{out,err,in}.

> If it's semantically like os.spawn and a little bit higher level
> abstraction than fork+exec, I'd vote for having the os module simply
> import it:

So os.spawnv and os.spawnve would be Windows-specific, but os.spawn
portable?  Could be confusing.  And despite the recent extended
discussion of the os module, I'm not sure if this fits the model.

BTW, is there anything like this on the Mac?  On what other OSs does it
even make sense to talk about programs spawning other programs?  (Surely
those GUI user interfaces have to do *something*...)

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913