sysexec - Transfer control to a UNIX-command
CommandArray sysexec -> -
CommandString sysexec -> -
These two calls are equivalent:
1. [ (ls) (-l) (/home/kupper) ] sysexec
2. (ls -l /home/kupper) sysexec
This call is NOT equivalent to the above (see remarks below):
3. [ (ls) (-l /home/kupper) ] sysexec
4. {(ls -l /home/kupper) sysexec} spoon
Look at the program environment of the new command:
5. {(printenv) sysexec} spoon
It was inherited from the SLI process.
Transfer control to a UNIX-Command. The command may be
executed in a specified program environment. The command
may be given either as a string containing the command
name and all options, or as an array of strings,
specifying the command name and every single option.
Alternatives: Functions sysexec_a for arrays, sysexec_s
for strings (both undocumented) -> behaviour and synopsis
are the same.
In : CommandArray
(array of strings): An array containing the command to execute.
The first element is interpreted as the
command, the remaining elements as it's
parameters.
CommandString
(string) : A standard UNIX command string, containing
the command name and it's parameters to
execute.
Out: -whatever will be will be-
Will break down if given an array containing non-strings.
This call is NOT quivalent to example 3, as one should expect:
(ls "-l /home/kupper") sysexec.
The reason is the breakup-command not recognizing ".
A call to sysexec WILL NOT RETURN, as control is literally transfered to
the UNIX command.
Given an array of strings, each element is treated as -one- parameter.
That's why example 3. is equivalent to the UNIX-call
ls "-l /home/kupper".
R Kupper
Mar 18 1999
/var/www/debian/nest/nest-simulator-2.20.0/lib/sli/processes.sli