https://gitlab.synchro.net/main/sbbs/-/commit/93db999e1565beed127812e1
Modified Files:
src/doors/syncdoom/syncdoom.c src/doors/syncduke/syncduke_config.c xtrn/syncdoom/install-xtrn.ini syncdoom.example.ini xtrn/syncduke/install-xtrn.ini syncduke.example.ini
Log Message:
syncdoom/syncduke: log to file by default, then hide the local console
Synchronet spawns a native door with CREATE_NEW_CONSOLE (sbbs3/xtrn.cpp),
so both doors pop a console window on the BBS machine for every session.
They draw to the CLIENT's terminal, so the window shows only diagnostics
-- but until now that console WAS the only place those diagnostics
existed: [debug] log defaulted to blank, i.e. logging off. Setting XTRN_NODISPLAY on its own would therefore have made a stock install
silent, with a hangup or a fatal recorded nowhere. That is worse than a
noisy window, so the two changes ship together:
- [debug] log now defaults to "syncdoom.log" / "syncduke.log", which a
BARE filename resolves to <SBBSDATA>/<door>/<door>_n<node>.log -- the
shared data dir, node-tagged from $SBBSNNUM. An explicit blank
`log =` still opts out; -log and $SYNC*_LOG still win.
- install-xtrn.ini gains XTRN_NODISPLAY, so Synchronet spawns with
CREATE_NO_WINDOW and no console window ever appears. A sysop who
wants it back turns it off in SCFG -> External Programs -> <door> ->
Disable Local Display. (Existing installs keep their flags; this only
affects a fresh install-xtrn run.)
Unlike syncalert -- which freopen()s stderr onto its node log and so can
call FreeConsole() unconditionally -- these two write structured entries
to a separate FILE* and leave the engine's raw stdout/stderr on the
console. Keeping the flag a plain setting, rather than baking a
FreeConsole() into the binary, leaves the sysop that lever.
Two traps found while testing the default, both of which made it a no-op
or a lie:
- Both doors return early when their .ini is absent (syncdoom.c's
read_syncdoom_ini(), syncduke_config.c's fopen guard), so a default
applied inside the ini block never runs on a stock install -- exactly
the case that most needs a log. Seed it on the no-ini path too.
- iniGetString() returns its default for a blank value AND a missing
key alike (xpdev ini_file.c), so a non-empty default made the
documented `log =` opt-out unreachable: the door logged anyway.
Use iniGetExistingString(), which returns NULL only when the key is
truly absent.
syncduke.example.ini's `log =` (blank) would have overridden the new
default straight back to disabled for anyone copying the template; it now
reads `log = syncduke.log`. Both example files also claimed a relative
path -- bare filename included -- lands in the per-user dir. That is
wrong for a BARE name, which both doors divert to <SBBSDATA>/<door>/
before the CWD matters; a relative path WITH a separator does resolve
against the per-user dir, because both doors chdir() there.
Verified on Windows for both doors across five configurations each: no
ini, ini without the key, ini with a blank `log =`, ini with an explicit
name, and -log overriding a blank ini. Compiled under MSVC only.
Co-Authored-By: Claude Opus 4.8 (1M context) <
noreply@anthropic.com>
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net