A copy/paste from websrvr.c

... that is working (for me at least) to auto load/rerun sbbs

This needed a custom solution (not errprintf) since the filename is passed-in
is likely from dynamically allocated memory, so a pointer comparison isn't
enough - and we don't get the function name.

This is a solution for issue #842, but only for messages posted/sent from the
terminal server using built-in functions and not via JS or other means. A more
universal/generic solution would be nice (beyond just always storing message
headers and bodies in UTF-8), but nothing has come to mind.

This reverts commit 79fa3c0b.

Differently than all other types, the length must be set before
parsing because the BPP does not contain the length data, instead
the length is specified by the message definition.

The expectation is now that there will be a single copy of SSH BPP
contents and arrays and buffers will be pointers into that.

This avoids another allocation/free requirement.

All consumers are expected to only #include deucessh.h now.  Individual
headers should not be included.

So require(..., 'node_status') instead. The function we actually use here.

and we weren't using that function here anyway, so require(..., 'node_status')
instead.

Looks like this feature (commit d661427e) never really worked correctly
since it counted the files removed from each sub-dir and then stopped deleting
when the count reached the number of files in the base directory. This was
done to accommodate the 'keep' feature (part of previous commits).
So make 'keep' check conditional on it being non-zero and just don't ever use
a non-zero keep value with a recursive delete and we should be good! :-)

This fixes issue #841

part of fix for issue #619

Part of solution for issue #619 (for the web server)

Part of solution for issue #619 (for the mail server)

For alignment with the text() method and for instances where a script author
doesn't want to load('text.js') or use [bbs|system].text.ID to get a text.dat
string index from an ID.

(which might be UTF-8 encoded). This works-around the problem that Accession
reported in #synchronet with my reply to a UTF-8 encoded message using a CP437
terminal which resulted in a message body that was UTF-8 encoded but a message
subject that was CP437 encoded. This mix of encodings is not supported by FTN
standards.

This is just a work-around since if the user modifies the subject the result
could still have the CP437 unside-down question marks (indicating
non-translatable UNICODE chars) and those should be converted to UTF-8
chars when going out on FTN or being stored in the message base. So there's
still a bug here somewhere that I need to look into more.

- when converting from CP437 to UTF-8
- when reading from RESULT.ED drop file

This effectively limited message subjects in some instances to 69 chars
instead of 70. This bug was caught while debugging a replied-message subject
conversion from UTF-8 to CP437 issue reported by Accession.

We have to use load() (rather than js.exec) to invoke str_cmds.js so that an
exit() will actually exit. Since load() automatically does the mods vs exec
directory search-dance, that simplifies the code in default.js a little.
I'm not sure exactly why I originally chose to use js.exec() over load() for
invoking str_cmds.js, but for this feature, we need load() so let's go with
that for now.

I did encounter an issue (issue #840) while originally trying to make this
work with the original code that called js.exec(), but just punted and went
with load() instead. Perhaps if we fix issue #840, we can revert default.js
back to using js.exec() (but why we would need/want to, I'm not sure).

ddfilelister: Check whether 'desc' is a string in file metadata before trying to use it. Should fix issue #839

Closes #839

See merge request !482

ddfilelister: Check whether 'desc' is a string in file metadata before trying to use it. Should fix issue #839

Since we we're not using opennodeext(), we don't have the path/fname for
any failure error message here.

CID 515714

This would cause the "Logout" status and multinode chat activity
strings to be truncated to 3 or 7 chars.

CID 515713 and 515715

System is going on a trip.

Use strlcpy instead of strncpy

This allows customized node actions/activity to be sent over finger/activeuser
(so visible in sbbsimsg.js for example).

Custom NodeStatus and NodeAction/Activity strings are now displayed pretty
much everywhere possible (except the node utility, since it doesn't read
any configuration files). This fixes issue #618, finally.

If you have custom (non-blank) NodeAction* strings in your text.dat/text.ini
file, or you change these strings during runtime (e.g. using bbs.replace_text)
this will impact you:
- do not include the user name or any other fields normally included in
  printed node status in your string - just the customized node action and
  really, you should only use/override these strings for dynamically changing
  node status (i.e. you're using NodeActionCustom and you're setting different
  custom strings depending on current node activity). Consider using the new
  NodeActivity* text.dat strings instead if your customized string doesn't
  change during run-time.
- don't use the %s/%u/%d specifiers any more - use @-codes instead, if needed

If you want static/permanent node action strings, set new new NodeActivity*
strings in your text.dat or (preferrbaly) text.ini file instead.
This means the node actions can now be localized for other languagues!

I'm still using the node.exb file (I did consider alternatives, e.g.
node.ini or node*/activity.asc), but decided to postpone such a change.
The node.exb file is still used, but the strings represent just the custom
(extended) node *activity* and not the entire node status string.

Use of Ctrl-A codes needs to be considered/accounted-for (currently isn't).

The newly created/used link_aera() function was copying the address of the
passed fidoaddr_t pointer rather than the value (fidoaddr) pointed to.
This is the actual fix for the problem reported by Tom Moore (1:135/205)
- tested and validated. It only immediately impacted areas.bbs use
(not areas.ini), since we wrote a stringified address directly to the
areas.ini file "links" key. This was not an allocation issue but a memcpy()
issue.

Other unrelated changes:
- Log a debug-level message when ignoring a "NO-ECHO" message (subject "NE:*")
- Log a notice-level message when ignoring a message due to GATEWAY VIOLATION
  (gating a message between net-types when not explicitly configured to do so)

So, (sizeof *addr) now looks right got me (this should've been the same as
sizeof(fidoaddr_t)), so the change in commit e2476ebb doesn't actually look
like a fix, but maybee a regression.

I need to test some area manager link additions and get to the bottom of this,
but this particular change was not a fix (and caught/reported by Coverity -
CID 515673).