src/sbbs3 xtrn.cpp 1.262 1.263
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv16614

Modified Files:
xtrn.cpp
Log Message:
Add support for %^ command-line specifer which expands to the system architecture (e.g. "i686" for Win32 builds, "x64" for Linux-x86_64 builds).
Currently, there underlying XPDEV macro definition does not differentiate between arm32 and arm64, but it should. Next...


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

https://gitlab.synchro.net/sbbs/sbbs/-/commit/ec5cbb848bc16419cc4267a9
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Fix compile issue in previous commit. Add more semicolons.

One can't have too many semicolons.

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

https://gitlab.synchro.net/sbbs/sbbs/-/commit/ccf41a4c15bfdbb1b1aa46d3
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Don't log blank lines output from external programs on *nix

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

https://gitlab.synchro.net/main/sbbs/-/commit/e2a9066d89af60010e8bf55b
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Fix Linux-DOSEMU buffer overflow warnings with sprintf() usage (!!!)

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

https://gitlab.synchro.net/main/sbbs/-/commit/8312547f3d4e276ac722b7df
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Trim left-most whitespace from stderr lines of externals before logging.

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

https://gitlab.synchro.net/main/sbbs/-/commit/ca424956d4f80d5d313b7eca
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Don't do the special DOSEMU cmdline specifier magic if the cmd starts with '?'

JavaScript modules are intuitively "native" and have not historically required the "native" option to be set to "yes" in SCFG.

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

https://gitlab.synchro.net/main/sbbs/-/commit/02a967b2403024c0a572eb45
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Trim white-space from the start of stderr-logged string from xtrns

... like the last commit that did this, but do in the other 2 places where stderr output is logged as log messages.
Also, include the extended program name in the stderr log messages, making it easier to find the output you're looking for.

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

https://gitlab.synchro.net/main/sbbs/-/commit/5a1ab6a7e8040e06aecf3868
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
A second pass at: Better native vs. DOS cmd-line detection in cmdstr()

cmdstr() is often called for non-executable command-lines (e.g. for @include: file name/path arguments), so don't default to native unless a mode value was specified. Hopefully addresses issue reported by bobrob without breaking anything else (again).

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

https://gitlab.synchro.net/main/sbbs/-/commit/87926cdac705ac979c403a5d
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Fix new GCC warning about unused variable.

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

https://gitlab.synchro.net/main/sbbs/-/commit/0e6853aeef28d32a26bc2c46
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Correctly support 1,000 arguments to an external

Previously, more than 999 arguments would overrun a buffer and break
things.

Fixes CID 33313

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

https://gitlab.synchro.net/main/sbbs/-/commit/7505f317f5581340ed1a9f60
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Fix use of uninitialized local variable (err_pipe[]) on *nix

And other weirdness around EX_NOLOG mode checks.
Addresses Coverity-scan CID 330048.

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

https://gitlab.synchro.net/main/sbbs/-/commit/9445866c80a38b5ee6c170ea
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Ignore VDD WriteFile() failures if the child process has terminated

If the child process (e.g. door game) has terminated, don't log errors if/when WriteFile() to the mailslot fails. This would be expected as the mailslot is created/owen-by sbbsexec.dll which would also terminate along with the process, thus closing the mailslot.

Hopefully resolves the errors reported by DesotoFireflite (VALHALLA).

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

https://gitlab.synchro.net/main/sbbs/-/commit/08ce315f97a09569f169ef89
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Suppress "VDD Open failed" warning if child process terminated

Another log message reported by DesotoFireflite (VALHALLA) that can happen when a user has typed something while the programming is running and the program terminates before the data can be sent to it.

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

https://gitlab.synchro.net/main/sbbs/-/commit/47e604723eb6eb602ed7e463
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
When running 16-bit DOS commands "offline" on Windows, don't use dosxtrn

We shouldn't need a virtual UART/FOSSIL driver to execute "offline" program (e.g. timed events) in the first place, and our virtual UART/FOSSIL for Windows wouldn't work right in the scenario anyway even if it did load successfully.

This resolves the reported issues with timed events configured as not "native" returning error 255 (and not running successfully) on Windows with SBBS v3.19. I'm not even sure what changed exactly in xtrn.cpp, dosxtrn.c, and sbbexec.c between v3.18 and v3.19 that's causing this to now fail, but it (using DOSXTRN to run offline DOS programs) really shouldn't have been attempted in the first place. So that was just a design issue that happened to kind of sort of work up until v3.19.

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

https://gitlab.synchro.net/main/sbbs/-/commit/e54263fde0be580dcbaf77c8
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Log command-line that led to logged error opening DOSXTRN.RET

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

https://gitlab.synchro.net/main/sbbs/-/commit/280f16f4f373956c17d2a5eb
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Add EXECDIR, DATADIR, and XTRNDIR to DOSemu command replacement tokens

As requested. This closes issue #416

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

https://gitlab.synchro.net/main/sbbs/-/commit/ce475f794e112fa9c9f435c6
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Don't log error opening DOSXTRN.RET when terminating an external

If we detect a client disconnection and terminate DOSXTRN.EXE, don't try to open DOSXTRN.RET and log an error when the file doesn't exist (as would be expected).

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

https://gitlab.synchro.net/main/sbbs/-/commit/e7109c87bc43f21636c5f981
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
When user hangs-up on external programs on *nix, try to terminate w/SIGTERM

Previously, when a user disconnected or ran out of time while running a stdio-based external program on *nix, if the program was still running, we'd send it a SIGHUP, wait up to 10 seconds for the process to terminate and if
it did not, terminate it (ungracefully) with SIGKILL. Since some programs
catch SIGTERM (and not SIGHUP) to indicate a termination request, we now will first attempt a SIGHUP, wait up to 5 seconds for the process to terminate and if it does not, then send a SIGTERM and wait up to another 5 seconds for it
to terminate and if it doesn't, then finally send it a SIGKILL (which cannot
be caught and always results in an ungraceful termination of the child process).

This doesn't resolve any specific problem with any specific stdio-based external program, but I was playing around with ESR's port of Adventure (https://gitlab.com/esr/open-adventure) and a new auto-save/restore of game state and noticed that we weren't using SIGTERM for this situation, though we should have. Most modern programs, if they catch SIGHUP at all, use it to indicate a refresh of configuration or data files, not a termination request (or indication that a user has "hung up"). So SIGTERM is more reasonable to be expected to be caught and initiate the graceful termination of the child program that we're hoping for.

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

https://gitlab.synchro.net/main/sbbs/-/commit/f78a70986d1e3b21b09ca32e
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Fix name of data event

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