When a preexisting node.log file is found, a terminal server crash is suspected. Include the timestamp of the node.log in the message appended to the system log (data/logs/*.log) to help identify the likely time of the crash.

Don't pass NULL to strcasestr().

when there is no "template directory" selected/configured.

When posting to "All" or replying to a message that was posted by networked (not local) user, don't attempt to search for that username in the local user base to inform them of the posted message to them.

savemsg() is the underlying C function for saving a new message (mail or post) to a message base from several places, including JS modules. If there was no "charset" specified in the passed message header, check to see if the message body text is non-ASCII but valid UTF-8, and if it is, set the FIDO_CHARSET header field to the appropriate UTF-8 charset identifier string. This would *also* address Issue #177 reported by Michael J. Ryan. It's possible, but unlikely, that a message text would contain valid CP437 that *also* happened to be valid UTF-8. If that does happen to occur (e.g. in posted ANSI art?), we might want to revert this enhancement to savemsg() and leave to the caller's to detect/specify the charset, always.

In Issue #177, the reported problem message header was "Content-Type: text/plain; charset=utf-8; format=flowed"
The fact that the "charset" value was not quoted and not space delimited means the charset would have been parsed as "utf-8;", which would not provide an exact match (against "utf-8") in smb_msg_is_utf8() and thus the message body would not be considered to be utf-8 encoded.

The solution is to terminate the "charset" parameter value at the semicolon, if it exists, and the value was not quoted.

Also, for good measure, only search for " charset" or ";charset" to avoid false-positive parameter matches,  like "notcharset".

For Windows release (CI) builds.

Caused error:
exec.cpp line 805 (sbbs_t::exec_bin) opening "s:\sbbs\exec\ÿÿÿÿÿÿÿÿ.bin" access=0
As reported by Nelgin via IRC at 3AM Texas-time.

Debugging why textgen is failing during Windows/CI build.

Previously, SyncTERM only supported the more modern XMODEM-1K uploads and XMODEM-CRC downloads. This commit adds support for XMODEM-128 uploads and XMODEM-Checksum downloads.

Kayz authored 4 years ago and Rob Swindell committed 4 years ago

This introduces pre/post execution modules for bbs.exec_xtrn. The logic previously in xtrn_sec.js for those functions is now in prextrn.js and postxtrn.js. These handle screen clear, evals, fonts, etc. Now everywhere that launches an external program will support these features

not just for Borland.

This allows us to ignore markup codes in a string like: "/sbbs/ctrl/*cnf*"

Addresses false-positive matches in URLs (e.g. https://minftn.net/) where the second slash was being interpreted as a the beginning of an italic markup.

In preparation for node-spy applications that can support multiple terminal sizes/types (none exist yet). The file is updated whenever there is new/updated information about the client's terminal.

Exposed as JS method: console.term_updated().

The "MAIL FROM" command argument must always be enclosed in angle-brackets. Some mail servers (e.g. gmail, aol) would reject messages not delivered in this manner, e.g.:
mx-aol.mail.gm0.yahoodns.net replied with:
"501 Syntax error in parameters or arguments tnmpmscs"
instead of the expected reply:
"250 ..."
gmail-smtp-in.l.google.com replied with:
"555 5.5.2 Syntax error. o6si11103060plk.317 - gsmtp"
instead of the expected reply:
"250 ..."

I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

It kinda sorta works, but needs more love.

The "insert key into keybuf" log line could contain garbage. Apparently
in a release build, the nested scope stack variable is actually invalid
after the end of the scope. Weird.

As reported by WitNik, on 32-bit rPi builds, the loop would not
terminate and display transfer count down values after hitting 'H'
to hang-up.

This reverts commit 9fd06985.

ERROR 2 (No such file or directory) in logout.cpp line 189 (backout) opening "/sbbs/node1/backout.dab"

format '%ld' expects argument of type 'long int', but argument 7 has type '__off64_t'

'%lu' expects argument of type 'long unsigned int', but argument 5 has type 'off_t

For non-authenticated SMTP clients, if the "From:" header field contains a "name" which appears to be an email address (i.e. it has an '@' in it), and that address does not match the *actual* address in the "From:" field, reject the mail with an error message about the forged/mismatched address.

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.

Originally, the "pause on exit" was implemented in the C++ version of
sbbs_t::xtrn_sec() and not sbbs_t::exec_xtrn(). This meant that the pause
option was only implemented when the prgoram was invoked from the menu and
not when invoked directly (e.g. via Baja or JS exec_xtrn function).

When sbbs_t::xtrn_sec() was ported to JS, that functionality was also moved
to JS. But it really should have been implemented in exec_xtrn() to begin
with so that regardless of how the program is invoked, that SCFG setting takes
effect.

Thanks to Michael Long for pointing this out.

Added an "All Servers" option.
Fixed the "Telnet server" (now "Terminal Server") to set the correct/modern semaphore file.
Simplified the implementation of this function.

So you can do stuff (*like this*).

Also, we don't need to heavily scrutinize the closing tag when we come upon it because we already determined it was valid before we accepted the opening tag/character.

This appears to go back to a change Deuce made in 2004 (rev 1.41) where ANSI, COLOR, RIP and WIP user terminal settings were always cleared when logging in via RLogin.

I happened to notice that manually enabling iCE color support wasn't working when logging in via RLogin (the iCE color flag would be cleared every login, but worked fine when logging in via Telnet). Upon investigation, I found that *all* user's manual terminal settings were cleared for either RLogin or SSH logins (copy/pasted bug). So... stop doing that. The method of dynamic terminal capability detection/checking has changed since 2004, so we should not need to mess with the user's misc flags.

The reported problem (by John "Jay" Crutti) was:
If autodetection of the terminal is used from the defaults menu I get stuck on the prompt to hit my Delete key because on the BBS, it keeps showing me login statistics every time I hit my delete key. 

Add/use new K_CTRLKEYS mode to stop inkey() from handling/eating control-keys (e.g. Ctrl-T) when asking user to hit backspace during defaults->terminal settings.

Allow PETSCII_DELETE (Ctrl-T) as a valid option when asking for the backspace/delete key and set the PETSCII flag in the autoterm variable if hit by the user.

Defaults to "Off" ("No") and can be set per-sub-board to either:
- "Yes" parse/apply markup style to displayed message text while still displaying the markup tags
- "Hide" parse/apply markup style to displayed message text and hide (don't display) the markup tags
- "No", treat marked-up messages the same as any other message text, same as before.

The supported Markup tags at this time are:
#bold text#
/Italicized text/
_underlined text_
#inverse text#

Now, ANSI-BBS terminals (and Synchronet) do not support the concept of italic or underlined text (at least, not yet) - so those styles become combinations of the blink and high-intensity attributes which can be used to choose alternate fonts and this works well.

These 4 styles were chosen to be compatible with GoldEd's "Style Codes", though GoldEd is actually very configurable in its support of these tags/codes and its possible we're not 100% compatible. For example, GoldEd (and SemPoint) both support the combining of tags/codes to created combinations of styled text - Synchronet does not (this is consistent with Mozilla/Thunderbird's "Structured Text").

Multiple words can be styled with a single set of tags, but the first and last word must be delimited by white-space (this is not consistent with Markdown).

Multiple lines can be styled with a single set of tags, but not multiple paragraphs (this is consistent with Markdown).

The rules I chose were to minimize false positives but maintain some interoperability with GoldEd and Thunderbird with a familiar/common tag syntax.

Don't let ANSI terminal control sequence, e.g. from 1337 FILE_ID.DIZs, leak into file descriptions.