... as requested by "ben" in #synchronet at irc.synchro.net

Currently, this assumes all stdio doors aren't "UTF-8 native", which might be
an incorrect assumption.

The "default" mnemonic string attributes are still set in ctrl/attr.cfg,
but now, each mnemonic string (e.g. from text.dat or passed to JS
console.mnemonics()) can include a "MNE:" @-code to over-ride the default
mnemonic string attributes (low, high, and command). If the "high"
attribute isn't specified, it defaults to the same color as the "low"
attribute with the "high intensity" flag flipped. The "cmd" attribute
defaults to whatever was included in the attr.cfg, if not specified.
Technically, the separator between the attributes can be any non-valid
attribute character (e.g. symbol).

Renamed (really old function) attrstr() to strtoattr() since its usage now
more closely resembles other std C strto* functions (has an 'endptr' arg).

dd_lightbar_menu.js: Changed the older KEY_PAGE_UP to KEY_PAGEUP and KEY_PAGE_DOWN to KEY_PAGEDN, as defined in key_defs.js

See merge request !433

dd_lightbar_menu.js: Changed the older KEY_PAGE_UP to KEY_PAGEUP and KEY_PAGE_DOWN to KEY_PAGEDN, as defined in key_defs.js

As reported by Chris/akacastor (21:1/162), SyncTERM would always assume the
Telnet session was in ASCII mode until/unless conn_binary_mode_on() was called
which is only called at the beginning of a file transfer, which sets the
conn_api.binary_mode accordingly. Unfortunately, if the Telnet server
requested binary mode itself (e.g. during initial connection), SyncTERM would
(try to) set the connection back to ASCII mode after any file transfer. :-(

With this change, the conn_api.binary_mode will track the actual binary TX
mode whether initiated locally or remotely (by the server), but it'll only be
set to true when *both* directions are succesfully set to binary mode. And
this way, if the connection was already in binary mode before any file
transfer, it'll remain in binary mode as was apparently desired by the server.

Also with this change, we could probably remove the setting of
conn_api.binary_mode to true/false in conn_binary_mode_on()/off() functions,
but it shouldn't hurt anything if it's left there I suppose (in case some
*other* terminal transport protocols have the concept of binary mode?).

Found by MSVC warning

This should now display pretty normally on both 40 and 80 column displays.

"FreeBSD" is 7 chars, so make that the max expected platform name (for now).

Addresses issue #746, request from Nelgin

Fix a long standing bug where by sysops could page for chat or send node
messages or telegrams to any node, even if there wasn't a user even connected.

Regular users were not affected by this bug.

Of particular interest is DoYouMeanThisUserQ since it wasn't a mnemonic
string before.

The string numbers for the last couple strings were wrong, corrected.

And use sizeof, not the magic number (again).

Deuce expanded the local 'error_code' buf to not trip the SAFECOPY macro
destionation buffer length check. Only this buffer needed to be 4 chars
exactly to truncate the 'message' string at 3 chars (e.g. just "404" for an
error message string that starts with "404 "). Switch from SAFECOPY to strlcpy
to eliminate this bug.

As reported by Ragnarok as part of issue #748

The web error files should work again.

Update to commit 85a2de04 (2 years ago).

FSC-74 specifies:
"The conference name shall be no more than 60 characters in length."

SCFG was limiting sub and dir area-tags to 40 chars and SBBSecho was limiting
area tags to 50 chars in length.

FSC-74 isn't a standard, but lacking this detail in FTS-4 and considering it
comes from the same authoritative source (the Conference Mail System User
Manual), I think it's the best source of truth we have.

Also, since we're no longer using .cnf files, we don't need different max
area-tag lengths between SBBSecho and SCFG structs - they all now use the same
macro: FIDO_AREATAG_LEN

Attempt to address error reported by Manitoo in IRC:
JavaScript sbbslist.js line 327: TypeError: bbs.network[network] is undefined

Normally, the "address:" key would always follow a "network:" key, but maybe
there's a corrupted message or the sysop is trying to import from the wrong
message base (not syncdata?).

Increase ansicode[] buffer size from 20 to 200 bytes due to this observed
crash when attempting to load an ANS file saved from PabloDraw:

Updated for Baja v2+ compatibility.
Updated for UNIX file system compatibilty.

Fix cosmetic, cross-platform, and other general "wrongness".

Added a CLEAR @-code to the top of qwk.msg

Lowercased and using the proper abbreviaton of "Oblivion/2".

Although the FILE_ID.DIZ suggests this is a clone of Oblvivion/2 v2.55,
the latest Oblivion/2 appears to be v2.40.

This shell source (in Baja) is a 99% copy of Yojimbo's (The Dojo BBS) Vision-2
shell source code from earlier in 1994.

The menu/display files need a little work, so they'll be committed separately.

I mainly wanted to commit this and then record the history of modifications
necessary to "modernize" the shell and at least get it compiling and useful
with recent versions of Synchronet BBS for Win32 and *nix and as demonstrated
at https://youtu.be/HlwQ0uX4S04

As reported by Fzf (FQBBS):

It addresses the local configuration but unfortunately it still doesn't set
remote options.  The remote is usually going to be in binary mode but SVDM has
the remote option set to ASCII by default.  A CR from the remote then gets held
up until a second byte is sent.

Also suggested by Fzf, when server_binary mode is not configured, then advertise
and request binary mode is/be disabled, explicitly.

... when using user_settings.js (i.e. to switch command shells), the user's
text.<lang>.ini is re-loaded, thus reverting any changes (e.g. made when
loading another shell, like simple.bin).

Also, this was causing the translated Pause strings (from text.<lang>.ini)
to be lost.

We're just using it to "fix" the case, if the file indeed exists.

If client socket is connected, wait up to the specified timeout period (in ms)
for the output buffer to be emptied.

This is much preferred over blindly calling mswait() after sending some data
(e.g. a file) and possibly waiting much longer than necessary.

Since the Terminal Server is a single thread, let's not block for long
periods of time trying to send bytes to a client (e.g. send the badip.msg
file contents to a client with a blocked IP address), effectively DoSing the
terminal server.

This should address the problem reported via IRC:
<theviper4> │Apr  9 15:38:11 viper-bbs synchronet: term Terminal Server timeout(outcom) 0000 0000
<theviper4> │Apr  9 15:38:35 viper-bbs synchronet: term Terminal Server !ERROR 110 sending on socket 39
<theviper4> │Apr  9 15:38:35 viper-bbs synchronet: term Terminal Server !ERROR 32 sending on socket 39
<theviper4> │Apr  9 15:38:35 viper-bbs synchronet: term Terminal Server !ERROR 32 sending on socket 39
<theviper4> │Apr  9 15:38:36 viper-bbs synchronet: term 0039 Telnet !CLIENT BLOCKED in ip.can: 117.95.153.33

Also, make the outcom timeout error message more helpful (e.g. include the
sock descriptor of the client) and don't use the old rioctl() function
here any more.

DDFileLister Fix: Searching by file date as a loadable module now does the new file search

See merge request !432

Oops

yes, this is a Y2K38 (or Y2106) issue, but we should have that worked out
when upgrading to the next libmozjs.

Need something like NUMBER_TO_JSVAL() and equivalent LAZY_NUMBER macro that
can deal with >32-bit ints correctly (or just always convert to double?).

... while the mods/*.bin command shell filenames could be any-case!

Only impacted non-Windows systems (UNIX file systems are case-sensitive).

Discovered while making this tutorial video: https://youtu.be/HlwQ0uX4S04

This is the time_t (seconds since Unix epoch, Jan-1-1970 UTC) date/time of the
current (most recent) Git commit used to build the running binary.

If a JS developer wants to check if a build is recent-enough to include some
change, this is the property they should use to check (with >= comparison).

Displays messages about non-existing files when in verbose mode

De-duplicate the data_dirs first (most sysops use a single data dir for all
file directories).

Also, don't print non-existing old files when run with -q (quiet) option.

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.