https://gitlab.synchro.net/main/sbbs/-/commit/4365aac62118b6e5a509f219
Modified Files:
src/sbbs3/jsexec.c
Log Message:
Don't compile the .ini parsing stuff for JSDoor

This should fix the recent JSDoor build issue introduced.

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

https://gitlab.synchro.net/main/sbbs/-/commit/8f4425cba02558a1c2c31fca
Modified Files:
src/sbbs3/jsexec.c
Log Message:
Enable JSOPTION_VAROBJFIX for JSDoor.

This option fixes the fact that the following two lines sometimes
place the variables in different scopes at the top-level of included
scripts:
var x = 1;
y = 2;

I plan to use this to experiment on if this is what's causing much
of the remaining scope chain weirdness... it certain explains some
things we've been seeing (and possibly even things like the METHODJIT
issues DigitalMan saw yesterday).

Enabling in sbbs/jsexec is a much bigger lift, but this change may
end up being all upside... the docs have suggested this option always
be set since it was originally introduced, and now that I understand
scopes better, it's pretty clear why that is.

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

https://gitlab.synchro.net/main/sbbs/-/commit/a64184e0046bdda67b3cdce1
Modified Files:
src/sbbs3/jsexec.c
Log Message:
JSDoor still needs the module name.

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

https://gitlab.synchro.net/main/sbbs/-/commit/aa4c080b13259eaa89016787
Modified Files:
src/sbbs3/jsexec.c
Log Message:
Typos in help

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

https://gitlab.synchro.net/main/sbbs/-/commit/3313031a70bb0b995e0006ea
Modified Files:
src/sbbs3/jsexec.c
Log Message:
Don't fclose(errfp) if it's NULL.

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

https://gitlab.synchro.net/main/sbbs/-/commit/d49facc893a919fefcb8969d
Modified Files:
src/sbbs3/jsexec.c
Log Message:
Flush console output stream after executing a script

Solves problem of status output lines being interleved with console
output (e.g. from print()) after executing a script.

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

https://gitlab.synchro.net/main/sbbs/-/commit/65bde885de939d6b1157382e
Modified Files:
src/sbbs3/jsexec.c
Log Message:
More verbose help output for -L option

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

https://gitlab.synchro.net/main/sbbs/-/commit/29001ba126bfd344c1f9ad63
Modified Files:
src/sbbs3/jsexec.c
Log Message:
This should allow it to link as a console program.

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

https://gitlab.synchro.net/main/sbbs/-/commit/20da5318bafa58eb3ead19e2
Modified Files:
src/sbbs3/jsexec.c
Log Message:
Fix (harmless) memory leak reported by ASan when running 'jsexec -?'

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

https://gitlab.synchro.net/main/sbbs/-/commit/cd997ea347ee9db7c5f3e474
Modified Files:
src/sbbs3/jsexec.c
Log Message:
Resource cleanup on exit (when no module specified)

Eliminates a SANITIZE build error

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

https://gitlab.synchro.net/main/sbbs/-/commit/40995ce1868fdb8cdbacf2a6
Modified Files:
src/sbbs3/jsexec.c
Log Message:
Insure the exec_dir is *always* prepped (fix for Windows upgrade to v3.20)

A "prepped" means directory means a relative path from the configuration files (or default settings) has been converted to a full/absolute path with proper slashes for the platform (i.e. backslashes instead of forward-slashes on Windows).

JSexec doesn't require that the new v3.20 ctrl/*.ini files exist to run; this was necessary to be able to run 'jsexec update -> upgrade_to_v320.js' which does the ctrl/*.cnf to .ini file conversion (egg not required to build chicken). When JSexec failed to load ctrl/msgs.ini
(e.g. "!ERROR loading configuration files: 2 (No such file or directory) opening /sbbs/ctrl\msgs.ini"), it would continue to run, but not "prep" any
of the "path" settings (e.g. exec_dir).

The first run of 'jsexec update.js' would fail to run upgrade_to_v320.exe (which does the v3.20 user base conversion) and a bunch of other (but not as important) update steps because Windows couldn't execute "../exec/*".

Multiple errors would be displayed in this case, but the most important (as reported by Ree in #synchronet of irc.synchro.net) was:
'..' is not recognized as an internal or external command

right after the status output:
No v3.20 user base found, running ../exec/upgrade_to_v320

Notice the "../exec/" prefix, which is not support by Windows when specifying
a file path to execute.

A second run of 'jsexec update' would work fine because the new v3.20 .ini files would be successfully created after the first run (though the user base was not).

This is likely the same issue that MRO reported recently when upgrading a Windows SBBS v3.19 install to v3.20 and not having the user base upgraded
the first time.

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