prevent threads from exiting while ids are beign changed.

the SIG33.

So, looking into this issue has shown me a number of things...
1) THE CAUSE FOR SIGWAIT FAILURE!!!
   The new Linux pthread model sends a "real-time signal" SIG33 to every
   thread when the saved, real, or effective user or group ID changes which
   then allows every thread to synchronize their IDs.  You cannot prevent
   this signal, and it causes the current syscall to fail.
2) Synchronet calls do_seteuid() quite often during startup and, when thread
   setXid is broken, every time a thread starts up.  As a result, you can
   get a storm of SIG33s.  Further, calling setXid() when not all threads
   have processed their SIG33 results in a deadlock apparently.
3) There is no apparent way of telling if all other threads have processed
   their SIG33s yet.

As a result, I've added a 10ms pause after a setXid() call to give it time
to work.  Since this happens while the mutex is held, it should work, but
10ms may be too large or too small or not effective.

This will add 10ms to EVERY threads startup time which will negatively
effect just about everything.  I'll be looking into the possibility that
setXid() is no longer actually broken on Linux and so we can reduce this
issue to only happening while Synchronet is still starting up, rather than
ongoing for every thread.

Thanks to everyone for their patience on the sigwait() failure issue.
Hopefully we'll be able to actually resolve this relatively soon.

NOTE: There will still be the sigwait failures during startup... the hope
is that we can prevent them from being an ongoing issue.

was linked with ciolib.  This seems to work perfectly on *nix and is untested
on Win32.

This *should* fix all the SDL-related stupidities that were occuring
previously (second system() call killing the program, etc).

Testers welcome!

setre?id() since new systems apparently hang on that call when the IDs
are already what you want.  Further, use a single mutex to protect both
do_setuid() and do_seteuid().

The symptoms:
When you connect to the BBS, the user prompt would repeat quickly three
times then drop carrier on you.  Nothing you entered ever showed up.
--OR--
You seem to connect to the BBS, but you never see any output.

This was only easily reproduced when starting the system as a non-root
user.

This has been confirmed on FC3, FC4, and Debian etch.


The cause:
output_thread or input_thread called thread_up() which called do_seteuid()
which hung in setregid().  Since do_seteuid() is holding a mutex at this
point, when the other *put_thread calls thread_up(), it waits forever for
the mutex.  If output_thread starts first, this results in getchr()
returning ^C every time it's called since input_thread_running is false.


Question for DigitalMan:
Should output_thread/input_thread post a semaphore when they're up to prevent
SMP systems from getting far enough into answer() to call IO stuff before the
corresponding thread is running?  A timed semaphore wait in main.cpp then
could be used (you wouldn't want to block forever in case this happens again).

variable names in the format:
XXXXX,#,STR
Where XXXX is the hex value of the CRC
# is zero if this is a bad match and non-zero if it's a good match.
STR is the variable string.

If you run unbaja with brute-forcing, and it makes a BAD match, adjust the
second value in the line and run it again to brute-force ignoring the bad
match.

At some point, I may have it pick up from the last variable.

Over twice as fast now baby... and that's a debug build.

Add a new -b## parameter...
This parameter will specify the number of characters to attempt brute-force
decoding of variable names to.
Using the stored bruted array would be a way of loading a dictionary too.

when exiting from last edit line.

Remove useless scope_chain property.

DIE DIE DIE!

DigitalMan hath spoken.

Make removecase() handle dirs as well as files through the use of a new
static delfiles_and_or_dirs() function which is basically delfiles()
with an option to remove() dirs too.
delfiles() simply calls this function now.

- Don't allow ? or * in the path
- Various bug-fixes

that exist.  Fix to delfiles() to delete from cwd if inpath is a zero-length
string.

use dest file as filename from editor.inf if subject is blank.

Sysops, rename all .pla files to .plan
Dance little SysOps dance!  BWA HA HA!

single function.
* editfile() now modifies a temporary copy of the file which solves 2 problems:
A. editors restricted to the temp dir (e.g. PICO) can now be used to edit other
    files (e.g. sig files)
B. DOS editors can now be used to edit files with long filenames
    (e.g. .plan files)

(not user-modifyable) - used for "New User Validation" e-mail.

- returns true/false if the user's terminal supports all the passed flags
- returns the supported flags if no flags are passed for comparison
- automatically uses the auto-terminal-type flags if no user is logged-on

in the if() - no functional change.