UMS config strings
  ~~~~~~~~~~~~~~~~~~

  Config strings are defined by lists of words.

  Words are seperated by whitespace (blanks, tabs, linefeeds).

  They  can  optionally be quoted (with double-quotes, "). Quoting
is  required for including whitespace or control-chars in strings.
  Within  quoted  strings,  the  backspace char (\) can be used to
create  certain control-chars: "\n", "\t", "\b", "\r", "\f", "\e",
"\[",  "\xHH"  yield  the  newline-,  tab-,  backsapce-,  return-,
formfeed-, escape-, CSI- or any hexadecimally coded character.

  The  first  word in the list is the name of the config-string to
define. Note that it can be quoted, too.


  References
  ~~~~~~~~~~

  All  other words (i.e. all except the name of the config-string)
can now also contain references to other config strings.

  Purpose
  ~~~~~~~

  References in config-strings offer a lot of additional power and
flexibility  to  your  UMS  configuration.  The idea is relatively
simple but when wisely used can reach a lot of goals:

 - allow to create various hierarchies of newsgroups and other
access-rights

 - reduce size of the ums-configuration (and thus memory
requirement of umsserver)
   - by avoid needless copying of strings
   - by using hierarchies of access rights which can be shared by
many users

 - provide the possibility to create "classes" of users

 - give a better structure to the config, greatly simplifying its
maintenance

 - obsolete the need for complicated AmigaDOS patterns. Just
combine simple "*-only" patterns

 - allow future optimization of umsserver speed


  Syntax
  ~~~~~~

  References  are indicated by the dollar character ($), which may
optionally be preceeded by an exclamation mark (!). Thus, whenever
a  word  starts with "$" or "!$", the rest of the word constitutes
the  name of another config-string which is to be inserted at that
place.
  References may also be quoted, but only after the dollar-char. A
dollar-char within double-quotes will, of course, will be inserted
literally.


  References in patterns
  ~~~~~~~~~~~~~~~~~~~~~~

  References in patterns are processed in a special way: as though
they were a single pattern.

  This  is  completely  different  from matching the config-string
after reading it as text!

  Not  only  in  the sense of not requiring a linefeed to separate
single  patterns,  but  also  in  the  way  all  the  patterns are
logically linked.

  References  introduced  with  "$"  constitute positive patterns,
those introduced with "!$" are negative pattern. Positive patterns
yield a logical OR operation of the result of previous matches and
the  overall  result  of referred config-string. Negative patterns
lead to a logical "AND NOT" operation.


  Scope
  ~~~~~

  Server  special  config-strings  only  try to resolve references
from  global  strings.  E.g.  a  user's  READACCESS  could contain
references,  but  the  user cannot sneak into disallowed groups by
locally creating suitable config-strings. READACCESS only resolves
its references from global config-strings.

  User-strings  use  login-local  and user-strings prior to global
strings  for  resolving  references.  This is also true for global
user-strings,  as  long  as  they are normally requested (i.e. not
"global-only"). See in the examples below how this can be used.


  Caveats
  ~~~~~~~

Beware of the follwing possible mistakes:

 -  unresolvable  references.  Only  refer  to strings that really
exist  in  the  scope  to  be  used!  When  UMS fails to resolve a
reference  it will simply insert a dollar-char and the name of the
reference and generate an error. This is not what you want.

 -   using   negative  references  as  text.  Negative  references
(indicated   by   "!$")   are   only  useful  for  patterns,  e.g.
access-patterns. They are not useful to be read as text.

 -  in  any  case:  strings with references designed to be used as
patterns or not useful to be read as text.

 -  editing strings with references as unquoted text is dangerous.
Especially when they were designed as patterns, unqoutedly reading
and   rewriting   config-strings  will  completely  destroy  their
original meaning.

 - cyclic dependencies. When trying to resolve strings with cyclic
dependencies, like ( a.b $a.b ), a stack overflow will occur. This
is handled, but an error will be generated, the result will be
unpredictable and unusable, and you risk running out of memory. So
be sure not to create cyclic dependencies.


  Examples
  ~~~~~~~~

( Sysname foo.bar.com )

# define hierarchies of groups for two networks
( groups.public.all $groups.public.anet $groups.public.bnet )
( groups.public.anet
    "anet.*\n"
    "!anet.sysop*\n"
)
( groups.sysop.anet
    "anet.sysop*\n"
)
( groups.public.bnet
    "bnet.*\n"
    "!bnet.sysop*\n"
)

# define hostnames for exporting mail
( hosts.anet "*.anet" )
( hosts.bnet 
     "*.bnet\n"
     "*.b.net\n"
     "*.bnet.com\n"
)

# a universal signature
#   with personal URL, assuming local system has a http-server
( Intuinews.signature
    "--\n " $name " <" $rfc.username @ $sysname ">\n"
    "WWW: http://" $sysname "/~" $rfc.username "/home.html\n"
)

# simple anet-user
( User
    ( Name "Alfred Ameise" )
    ( Alias alam "Alfred Ant" )
    ( rfc.username "alam" )
    ( Readaccess $groups.public.anet )
    [..]
)

# simple bnet-user
( User
    ( Name "Berta Biene" )
    ( Alias bebi "Bertha Bee" )
    ( rfc.username "bebi" )
    ( Readaccess $groups.public.bnet )
    [..]
)

# advanced user with special rights in anet
( User
    ( Name "Camilla Chamäleon" )
    ( Alias caca "Camilla Chameleon" )
    ( rfc.username "caca" )
    ( Readaccess $groups.sysop.anet $groups.public.all )
    [..]
)

# exporter for anet mail
( Exporter
    ( Name export.anet )
    ( Export $hosts.anet )
    [..]
)

# exporter for bnet mail
( Exporter
    ( Name export.bnet )
    ( Export $hosts.bnet )
    [..]
)

# exporter for all other mail
( Exporter
    ( Name export.anet )
    ( Export "*" !$hosts.anet !$hosts.bnet )
    [..]
)