• src/sbbs3/exec.cpp

    From Rob Swindell 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.
  • From Deuc╨╡ 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.
  • From Rob Swindell 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.
  • From Rob Swindell (on ChromeOS) 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
  • From Rob Swindell (on Windows) 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
  • From Rob Swindell (on Windows 11) 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.
  • From Rob Swindell (on Windows 11) 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.
  • From Rob Swindell (on ChromeOS) 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).
  • From Rob Swindell (on Windows 11) 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.
  • From Deuc╨╡@shurd@sasktel.net 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).
  • From Rob Swindell (on Windows 11)@rob@synchro.net 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
  • From Rob Swindell (on Debian Linux)@rob@synchro.net 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.
  • From Rob Swindell (on Debian Linux)@rob@synchro.net 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.