to the bottom of Alterego's reported issue with new mail message bodies not
being displayed.

already creates the dirs that were of concern (Transfser File Paths). May
want to DLL-export this and call from here later.

in novice menu mode. :-)

line-counters knows the sysop (*not* in expert menu mode) hasn't seen the
printed-result.

Fixed typo in other log msg.

can't use it as an argument to sprintf(str, ...)
Also, use getfname()... more.

js_socket.obj : error LNK2001: unresolved external symbol _in6addr_any

This is a symptom of an error in the ircd, but we can't count on that being
fixed everywhere.

Add a /QUOTE command to send unsupported commands.
Remove some development logging.

Next up, send messages better.

<nelgin> If sysop used /die then sbbs irc client quits with an ugly message :)
<nelgin> !JavaScript  irc.js line 625: TypeError: sock.recvline() is null

Also fixed the spelling of "receive_command"

This caused an off-by-one error in bans.

 scfg
 validates/creates directories when you save the file area config but they are
 missing the '/' between "dirs" and the internal code...

So the Transfer File Path auto-default-value logic is actually in 3 places:
- load_cfg.c prep_cfg()
- scfgsave.c write_file_cfg()
- scfgxfr2.c dir_cfg() - for display purposes only

<sigh>

colons inside are part of the field.

code. Compare against full internal-code (not just suffix) for duplicate
detection.

directory), ignore dirs that are already configured, i.e. internal code
suffix matches the sub-dir name.

in load_cfg.c for displaying the path. If you previously had a "parent dir"
configured for a library but did *not* have one or more "Transfer File Paths"
configured for directories within that library, the default location of your
files has now moved! Either clear-out the "Parent Directory" setting or move
your files where SBBS will now expect them to be. Sorry about that.

be sure all necessary dirs are created.

default-setting.
- If a directory's Transfer File Path is not set (blank), and the library
  has a "parent directory" configured, then the default Transfer File Path
  will (now) be <parent>/<dir-code>, where <dir-code> is the directory's
  internal code (lower-cased). This is different from previous behavior where
  the parent dir was not used unless *something* was entered for a dir's
  Transfer File Path. I'm sorry if this brakes your b0rad!
- If a directory's Transfer File Path is not set (blank), and the library does
  *not* hae a "parent directory" configured, then the behavior should be the
  same as before, default Transfer File Path: <data-dir>/<dir-code>
- If a directory's Transfer File Path is already set to a
  full path, there should be no change in behavior either.