https://gitlab.synchro.net/main/sbbs/-/commit/9d752c75a8cc86f782744075
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Install OperationCallback for all executed JS scripts

JS doors with the "Use Shell or New Context" option enabled in SCFG and JS modules installed a global hot key handlers would not automatically terminate when the user disconnected (and js.auto_terminate was true, the default).
I'm not sure why the operation callback was only installed when scope==NULL
but always installing it fixes the issue with some global hot key modules
and JS doors becoming "zombies" when a user disconnects while running them.

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

https://gitlab.synchro.net/main/sbbs/-/commit/c97490f1325101d8e97e20cf
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Don't call putuserdat if the user number is invalid (not logged in)

This should fix issue #626

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

https://gitlab.synchro.net/main/sbbs/-/commit/bbe9979815e99664290c9683
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Don't decrement user.xedit before calling uselect()

This bug would leave the user's external editor setting decremented by one if they aborted (with Ctrl-C).

Fixes issue #631

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

https://gitlab.synchro.net/main/sbbs/-/commit/00379de8fd71dbb0009e2492
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Only log a single error message when js_execfile() detects a NULL JS Context

js_execxtrn() now returns -1 if a JS context can't be created. This eliminates redundant error messages from calling js_execfile with a NULL context.

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

https://gitlab.synchro.net/main/sbbs/-/commit/648f020d426dfd7bde139231
Modified Files:
src/sbbs3/exec.cpp
Log Message:
Don't clear the console-abort flag upon return from executing a JS module

This completes the revert of commit c22063f9 from (Jun-2-2016). The Baja
part of that commit was reverted in commit 932fae30 (Nov-15-2016). This behavior has proven to be surprising and annoying for JS mod developers
(e.g. the yesnobar.js and Nightfox's file searcher/scanner).

If we still need clearing of abort status after running JS "externals",
that should probably be done in exec_xtrn(), not here.

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

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