• src/sbbs3/exec.cpp

    From Rob Swindell@VERT to Git commit to sbbs/master on Sun Aug 30 13:32:39 2020
    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
  • From Rob Swindell@VERT to Git commit to sbbs/master on Tue Nov 3 23:49:30 2020
    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
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Wed Nov 25 17:46:10 2020
    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
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Wed Nov 25 22:01:38 2020
    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
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Jan 23 18:51:59 2021
    https://gitlab.synchro.net/main/sbbs/-/commit/47f8c020a88939d18a033542
    Modified Files:
    src/sbbs3/exec.cpp
    Log Message:
    JS module command-lines now supported quoted arguments (w/white-space)

    Example:
    Command-line: ?showargs " a b c "d "e f"
    argc = 3
    argv[0] = ' a b c '
    argv[1] = 'd'
    argv[2] = 'e f'

    This resolves a long-standing TODO comment.

    Also, fixed a problem where multiple spaces between the module name and the first argument would result in argv[0] being set to an empty string.
    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Sun Apr 4 19:31:36 2021
    https://gitlab.synchro.net/main/sbbs/-/commit/30ebfa0a61f9fbffdd42cc93
    Modified Files:
    src/sbbs3/exec.cpp
    Log Message:
    Have js_execfile() save/restore callbacks

    This should allow callbacks to not interfere between (say) shells
    and doors.
    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sun Apr 10 20:27:59 2022
    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
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Sun Sep 10 15:08:51 2023
    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
  • From Rob Swindell (on Windows)@VERT to Git commit to main/sbbs/master on Thu Sep 14 21:28:57 2023
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sat Nov 11 13:07:10 2023
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sat Dec 30 17:49:02 2023
    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
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Sat Mar 30 15:37:41 2024
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Fri Apr 5 17:41:05 2024
    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
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Mon Jan 20 19:41:59 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/ed8c30dabfca6158b3e9207a
    Modified Files:
    src/sbbs3/exec.cpp
    Log Message:
    Don't call JS_GC() after js.exec() until new background threads exit

    Hopefully this will fix the occasional crash in the testsuites
    (and presumably, occasional crash in other things that use background
    threads with js.exec(), if there are any).
    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Mon Jan 20 19:54:50 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/7eb498aa080dc3bcd8162ff8
    Modified Files:
    src/sbbs3/exec.cpp
    Log Message:
    Fix MSVC link error
    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Mon Jan 20 20:12:28 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/02e9b75c6ed7311b09c1473d
    Modified Files:
    src/sbbs3/exec.cpp
    Log Message:
    Revert "Fix MSVC link error"

    This reverts commit 7eb498aa080dc3bcd8162ff8c2b7e9a9448d4372.
    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Mon Jan 20 20:12:28 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/6f3cf9b198f9ba0a8fd5b253
    Modified Files:
    src/sbbs3/exec.cpp
    Log Message:
    Revert "Don't call JS_GC() after js.exec() until new background threads exit"

    This reverts commit ed8c30dabfca6158b3e9207a9f36f4fde0dd5f3a.
    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net