https://gitlab.synchro.net/main/sbbs/-/commit/9013f866a8231f39f066fc9b
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Save and restore the js.exec_path, exec_dir, and exec_file properties

When invoking a nested JS script, these properties of the "js" object would
be overwritten and not restored, as discovered/reported by Nightfox when his trivial game script would indirectly execute yesnobar.js, his subsequent use
of js.exec_dir would point to the wrong location (the "exec" directory, parent of yesnobar.js, and not the direcctory where his game script was located).
The exec_path and exec_file properties had the same problem as demonstrated
by a simple test.js placed in (and executed from) a directory other than the "exec" dir:
function f() {
print("js.exec_path = " + js.exec_path);
print("js.exec_dir = " + js.exec_dir);
print("Js.exec_file = " + js.exec_file);
}
f();
console.yesno("test");
f();

This would only trigger the problem when executed from the BBS and whebn the YesNoQuestion text.dat string invokes the "yesnobar" module via EXEC @-code and yesnobar.js exists (in exec or mods dir), superceding yesnobar.bin which does not trigger this issue (not a JavaScript mod).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c3b47aca928c693687eefcaa
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Save/restore js.scope property value in sbbs_t::js_execfile()

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/256251869f924e3acc9ffb8d
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Previous commit fixed issue with JS_GC before JS_ENDREQUEST

So revert the order back to the way it was in aa2bcd61e9017816d06e581eef478 (don't you love these git references?).

Also, the previous fix for js_execfile() calls for global hot-key events also fixed the EX_JS_CX feature I was working on (js_execmodule)!

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/175d0fbc996e5292480bab8e
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Always evaluate js.on_exit() installed expressions.

I noticed that when executing an external JS with the new "Use Shell / New Context" option set to "Yes", that any expressions (strings) installed via js.on_exit() were not being executed upon exit from the script. These on-exit strings are important for restoring global state information (e.g. control key pass-through, console mode) to the original state before the JS mod made any changes.

I'm not sure why the special treatment of "scope == NULL" is through-out this function. Going back to v3.16, it appears this was special treatment for JS mods invoked via global hot key event (when scope != NULL). When invoking an xtrn JS mod with the new Context option, the scope argument is not NULL, so this check was defeating the parsing of the "exit_code" and the evaluation of any js.on_exit() installed expressions for no apparent reason. I can't think why global hot key events should be excluded from this logic either.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b287a8d0887dce091a965ede
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Log a better error when attempting to execute a non-existent module.

Don't complain that exec/<modname>.bin can't be opened. Instead, complain that <modname> doesn't exist and therefore can't be executed. The old message could be misleading/confusing if the expected module is a JS mod (not Baja-compiled .bin mod).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/10d7a690029318dc4ff59ffa
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Merge branch 'master' of gitlab.synchro.net:main/sbbs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net