Hi,
When a process spawned by ksh inside a ksh function (declared with the
'function' keyword) is killed, the script gets killed as well. This
happens only when the spawned process is the last command inside the
function. The following scripts demonstrates this behaviour:
################################
#! /bin/ksh
function gosleep {
/bin/sleep 1000
#true
}
print "starting first sleep"
gosleep
#/bin/sleep 1000
print "starting 2nd sleep"
gosleep
#/bin/sleep 1000
################################
Once this script is running, kill the sleep process with a SIGTERM and
watch the entire script get terminated. If the function declaration is
changed to posix style, the behaviour is not seen. Also, if the
command 'true' at the end of the function is uncommented, this
behaviour is again not seen (since it wipes out the exit status).
A code study indicates that the return status of the function is
explicitly monitored for any signals received:
int sh_funscope(int argn, char *argv[],int(*fun)(void*),void *arg,int execflg)
{
...
/* My comment: The function being spawned */
sh_exec((Shnode_t*)(nv_funtree((fp->node))),execflg|SH_ERREXIT);
r = shp->exitval;
...
/* My comment: If a signal has been recorded in the exitval, commit
sepuku */
if(shp->exitval > SH_EXITSIG)
sh_fault(shp->exitval&SH_EXITMASK);
...
}
So it seems like expected behaviour. But there is the inconsistency
where the signal received matters only if the forked process is the
last one in the function listing. So in essence, the function only cares
about the exit status of the last process in the listing. This is OK for the
exit value, but should that also be the case for signals? Shouldn't the
signal status matter for all processes or not at all?
Thanks,
Siddhesh
--
Siddhesh Poyarekar
http://siddhesh.in
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
