| Name: | spawn - Spawn a UNIX process and redirect stdin and stdout.
|
| Synopsis: | CommandString spawn } { Flag=0: Status NormalExitFlag
CommandArray spawn } {
} { Flag=1 or omitted:
CommandString spawn } -> { ear(write) mouth(read)
CommandArray spawn } {
} { Flag=2:
CommandString Flag spawn } { ChildPID ear(write) mouth(read)
CommandArray Flag spawn }
|
| Description: | "spawn" does exectly what "system" does (see there).
If Flag is 1 or 2, in addition, it redirects the spawned
processes standard input and output to pipes that are then
accesssible from the parent process.
If you are interested in monitoring the information flow across
the pipes, see "shpawn".
Alternatives: Functions spawn_as_i with array or string
followed bey an integer (flag), spawn_as_di_i with array
or string and dictionary followed by an integer (both
undocumented) -> behaviour and synopsis are the same.
|
| Parameters: | In : CommandString(string), CommandArray(array of string):
See "system"
Flag(0|1|2) (Default=1):
The Flag parameter is passed to "system":
0: "spawn" behaves absolut identical to
"system" (see documentation).
1 or omitted: "system" is called in no-care-mode
(see documentation). Pipes to standard
input and output of the new Process are
established.
2: "system" is called with Flag=2.
(see documentation). Pipes to standard
input and output of the new Process are
established. The Child's PID is returned,
for the user has to call "waitPID" expli-
citely.
Out: Status(integer), NormalExitFlag(boolean): See "system"
ChildPID(integer): Process ID of the child process.
Remember to call wait on this PID!
ear(ostream): The write end of the pipe that is connected
to the child's standard input. You can access
the child's standard input by writing to "ear".
mouth(istream): The read end of the pipe that is connected
to the child's standard output. You can access
the child's standard output by reading from "mouth".
|
| Examples: | 1. %Spawn "ls" and read output from the pipe:
(ls) spawn %spawn ls in no-care-mode
exch closeostream %we do not need to write to ls!
{ eof {exit} {getline =} ifelse } loop %read and display data.
closeistream %close connection
2. %Spawn "idl" and display output in SLI's callback cycle:
(idl) spawn %spawn IDL in no-care-mode
/IDL_mouth Set
/IDL_ear Set
%This procedure reads data from idl as long as it is available
%and displays it on the screen:
/IDL_talks
{
IDL_mouth
{ available
{getline =}
{exit}
ifelse
} loop pop
} def
%Hang this Procedure into callback cycle:
/IDL_talks load setcallback
%You may now issue IDL commands by sending them to IDL_ear
%Output will be displayed on the screen:
IDL_ear (help, !VERSION, /STRUCT) <- endl
3.%Instead of using SLI's callback cycle to display the output,
%we could have used a parallel SLI process instead:
{ IDL_mouth {getline =} loop } spoon
%In this case we even don not care about blocking...
|
| Diagnostics: | -see section "Bugs"-
|
| Bugs: | No error message is raised, if Flag=1 or Flag=2 and the given
UNIX-command does not exist. To be correct, an error -is- raised,
but it is raised in a child process of SLI, and -after- standard
output has been redirected. The error message can be read from
the "mouth"-pipe!
"spawn" always returns sucessful if Flag=1 or Flag=2. However,
excution of the UNIX command may have failed in the child process.
This may be a bug or a feature, whatever you like best ;->
|
| Author: | R Kupper
|
| FirstVersion: | May 06 1999
|
| Remarks: | "spawn" uses "system"'s Precode-Feature. (Caution - sophisticated
programming style!!! ;->)
For further remarks, see documentatin of "system".
If you are interested in monitoring the information flow across
the pipes, see "shpawn".
To Do: In some cases, we will not need both the standard input and
output redirected, but only one of them. In future versions,
"spawn" may have the option to redirect only one of them.
Respectively, there should by the option to redirect standard
error as well. Possible calling sequence:
command Flag stdinflag stdoutflag stderrflag spawn
with stdinflag, stoutflag true as default, stderrflag false.
It should be possible to spawn a parallel SLI Process. This
should be supported by a future version. Actually, as this is
the more general case, the spoon/system/spawn chain of commands
could be restructured.
| SeeAlso: | system pipe available wait environment |
|
| Source: | /home/abuild/rpmbuild/BUILD/nest-2.4.1/lib/sli/processes.sli
|