1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/sbbs3/exec.cpp

    From rswindell@VERT to CVS commit on Thu Oct 4 17:23:00 2018
    src/sbbs3 exec.cpp 1.105 1.106
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv29468

    Modified Files:
    exec.cpp
    Log Message:
    Log an error when attempting to execute a 0-byte .bin file.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Thu May 9 10:00:14 2019
    src/sbbs3 exec.cpp 1.108 1.109
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/home/rswindell/sbbs/src/sbbs3

    Modified Files:
    exec.cpp
    Log Message:
    if sbbs_t::exec_bin() is called with a blank or NULL module name, just
    return an error value (-33, it's the magic number).



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Mon May 27 21:49:00 2019
    src/sbbs3 exec.cpp 1.109 1.110
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv27351

    Modified Files:
    exec.cpp
    Log Message:
    Optimize: don't search for file extension repeatedly.



    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to sbbs/master on Sun Aug 30 09: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 18: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 12: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 17: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 13: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 15: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 16: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