-
Rob Swindell authored
This solves the problem of exit() values (e.g. non-zero return codes) not getting propagated to callers when nest-called (e.g. via bbs.exec()). I think it was kk4qbn that pointed this out via IRC: an exit(1) call from prextrn.js did not stop the external program from running (as it should, for any non-zero exit code). This only happened when the prextrn.js called another JS script (e.g. via bbs.exec() or as was the case here, indirectly via "EXEC" @-code in the YesNoBar text.dat string (which executed yesnobar.js). This nested JS script invocation via sbbs_t::js_execfile() would clobber the stored js.scope property value (where the "exit_code" property is written). Script invoked in their own context (e.g. via js.exec()) wouldn't have this issue in the first place.
Rob Swindell authoredThis solves the problem of exit() values (e.g. non-zero return codes) not getting propagated to callers when nest-called (e.g. via bbs.exec()). I think it was kk4qbn that pointed this out via IRC: an exit(1) call from prextrn.js did not stop the external program from running (as it should, for any non-zero exit code). This only happened when the prextrn.js called another JS script (e.g. via bbs.exec() or as was the case here, indirectly via "EXEC" @-code in the YesNoBar text.dat string (which executed yesnobar.js). This nested JS script invocation via sbbs_t::js_execfile() would clobber the stored js.scope property value (where the "exit_code" property is written). Script invoked in their own context (e.g. via js.exec()) wouldn't have this issue in the first place.