Provided by: libatfs1_1.4pl6-16_amd64 bug

NAME

       BindRules - ShapeTools version bind rules

DESCRIPTION

       The  ShapeTools  version  binding  subsystem  (see  vbind(1))  provides  a  mechanism  for
       expressing general version bind rules. These rules describe on an abstract  level  version
       properties,  which  will be matched against the properties of concrete versions during the
       version bind procedure. The goal is to select one or more versions from a named history in
       order  to  provides  access  to  these  version(s).   A  version  bind operation is always
       performed for exactly one history at a time. Version bind rules express something like

            Select the most recent saved version.
            If there is no saved version, select the busy version.

       ShapeTools however needs rules in a more formal notation to be  able  to  interpret  them.
       Let's see, how the rule above is translated into the formal notation.

       Version  bind rules consist of a list of attribute expressions evaluated one after another
       until one of the expressions leads to a unique version identification. The expressions are
       separated  by semicolons, the last expression ends with a period. The rule from above will
       now read:

            Select the most recent saved version ;
            Select the busy version .

       Each attribute expression consist of a  list  of  predicates,  separated  by  commas.  The
       predicates  are  evaluated  from  left  to right resulting in a hit set, a set of versions
       fulfilling all predicates  evaluated  so  far.  The  initial  hit  set  for  an  attribute
       expression  contains  all  versions  of  the  name to be bound. Each predicate potentially
       narrows the hit set. The predicates in our rule are:

            all saved versions , most recent version ;
            busy version .

       Remember, that each predicate bases it's selection on the hit set left  by  the  predicate
       before.  Hence exchanging the two predicates in the first attribute expression may lead to
       different results. We will give more information on this topic in the  section  about  the
       evaluation  algorithm below. We now reach the final form of ShapeTools version bind rules.
       The predicates must be taken from  a  list  of  predefined  names  and  be  equipped  with
       arguments:

            ge (status, saved) , max (stime) ;
            eq (status, busy) .

       That's  it  so  far.  This  is  a  rule  how  ShapeTools  understands it.  It does however
       illustrate just a small piece of the world of version bind rules. We will go  on  in  this
       manual page with a detailed description of version bind rules divides into the sections

       RULE HEAD           Description of the structure of rule heads.

       EVALUATION ALGORITHM
                           The Algorithm how version bind rules are evaluated.

       NAME PATTERNS       Name patterns as first predicate in attribute expressions.

       PREDICATES          List of valid predicates.

       ATTRIBUTES          A  List of predefined attribute names and some word about the ordering
                           relationship between attribute values.

       EXPANSION           Description of the  various  types  of  expansion  such  as  parameter
                           substitution, attribute and macro expansion, and command substitution.

       LEXICAL STRUCTURE   Lexical constraints for names and strings in version bind rules.

       TIPS, TRICKS, AND TRAPS
                           Some common problems.

       GRAMMAR             A complete grammar for version bind rules.

RULE HEAD

       A  version bind rule consists of a rule head and a rule body. The example above shows only
       the rule body. The rule head defines a name for the rule and optionally a parameter  list.
       The name is a string consisting of any printable non-whitespace character except colon and
       parentheses. It is followed by an optional parameter list  in  parentheses  and  a  colon,
       delimiting the rule head. Multiple parameters in the list are separated by comma. Examples
       are

            most_recently_released:

            from_release (release_name):

            last_released (library_path, include_path):

EVALUATION ALGORITHM

       The basic idea of the rule evaluation algorithm is, that in every state  of  processing  a
       hit  set  exists, a set of versions reflecting the current rule evaluation result. The hit
       set is initialized with all versions of the given name at the beginning of each  attribute
       expression.  The  attribute expressions predicates are processed from left to right in the
       order they occur. Each predicate imposes requirements to the versions in the hit  set  and
       eliminates  all  versions  not  fulfilling  these  requirements.   So, the hit set becomes
       smaller  and  smaller  during  attribute  expression  evaluation.  The  following   figure
       illustrates  this  process together with the rule most_recently_released defined above and
       the file foo existing as busy version and as versions 1.0 through 1.2.

           Initial hit set:    ( foo[busy], foo[1.0], foo[1.1], foo[1.2] )

           Evaluate Predicate: ge (status, saved),

           New hit set:        ( foo[1.0], foo[1.1], foo[1.2] )

           Evaluate Predicate: max (stime);

           Final hit set:      ( foo[1.2] )

       When the hit set becomes empty, that is when no version meets all the predicates evaluated
       so  far,  the  attribute  expression  fails  and  processing  is finished immediately. All
       remaining predicates will not be evaluated. Even remaining predicates without influence on
       the  hit  set (for example message predicates) will not be processed. Processing continues
       with the next attribute expression. If all attribute expressions finish  prematurely,  the
       whole  version  binding  fails.  In  the following example, the first attribute expression
       fails and the second alternative leads to success.

           Initial hit set:    ( bar[busy] )

           Evaluate Predicate: ge (status, saved),

           New hit set (empty):( )

           Evaluate next attribute expression
           starting with initial hit set again:( bar[busy] )

           Evaluate Predicate: eq (status, busy);

           Final hit set:      ( bar[busy] )

       When evaluation reaches the end of an attribute  expression  without  the  hit  set  being
       empty,  two  cases  are  possible.  First,  the  hit  set contains exactly one version and
       everything is fine. This is usually the desired state  and  rule  evaluation  returns  the
       remaining  version  as bind result. Second, the hit set may contain more than one version.
       In this case, the evaluation algorithm depends on  the  expected  result.  When  a  unique
       version  binding  is  expected, this is treated as failure and evaluation goes on with the
       next attribute expression. Non-unique version binding regards this as success and  returns
       the whole hit set.

       Extending  the  hit set during evaluation of an attribute expression is not possible. This
       would be against the nature of the version bind  rules  and  would  make  them  much  more
       difficult  to  understand.   Hit  set  extension  may  only  happen by letting the current
       attribute expression fail and begin with a new one and the maximum hit set.

       Failure of an attribute expression must not necessarily be caused by an empty hit set.  It
       may  also  be  caused  by user interaction or by external constraints. The following rules
       exemplify user interaction:

           eq (state, busy), confirm (select busy version ?, y);
           ge (state, busy), max (version).

       where the user will be asked for confirmation to select the  busy  version,  and  external
       constraints:

           exists (otto, 1.0), eq (state, busy);
           ge (state, busy), max (version).

       where  selection  of  the busy version happens only, when version 1.0 of otto exists (this
       example is somewhat silly).  Predicates like confirm and exists don't care about  the  hit
       set.  They provide the possibility to impose external control on the evaluation of version
       bind rules. An attribute expression may be finished prematurely and  control  switches  to
       the next one.

       There  is  another  operator,  the  cut  operator, that forces the whole bind operation to
       finish (and fail). Typically the cut operator stands at the end of an attribute expression
       that  should  never  succeed.  The following is a typical example for use of this. Version
       binding fails, if there is an update lock set on the most recent version.

           max (version), hasattr (locker), cut (history is locked !);
           max (version).

       The cut operator accepts a string argument that will be written to the standard output.

NAME PATTERNS

       Each attribute expression may start with a pattern, against which the name to be bound  is
       matched.  Only  when  the name matches the pattern, the corresponding attribute expression
       will be evaluated. If not, the attribute expression will be skipped.  When the pattern  is
       omitted in the attribute expression (as in our example above), the expression is evaluated
       for each name.

       The patterns are the same as those recognized by sh(1)  for  filename  generation  on  the
       command line. Magic cookies are:

       *       matching any string, including the empty string,

       ?       matching any single character,

       [c...]  matching any one of the characters enclosed in the square brackets,

       [l-r]   matching any character lexically between the left (l) and the right (r) character,
               inclusive, and

       [!c...]

       [!l-r]  matching any character not recognized by their counterparts above.

       A rule with name patterns for example looks like:

           xyyz.h, eq (version, 1.3);
           *.c,    eq (generation, 2), max (revision);
           *.h,    eq (generation, 3), max (revision).

       In this example, version binding for C source files (most recent version  from  generation
       2) is different from version binding for header files (most recent version from generation
       3). Additionally, the name xyyz.h will always be bound to version 1.3.

       If the name to be bound is given together with a (absolute  or  relative)  pathname,  this
       will  not  be  cut  off. The match is always performed lexically for the whole name given.
       Hence, the name pattern may also contain path names, like

           variant1/*, eq (alias, var1-1.4);
           variant2/*, eq (alias, var2-1.2);
           /usr/sample/include/*.h,max (revision).

       Usually, the version bind subsystem does not check, if different path prefixes in the name
       pattern  and  the  given  name  to  be  bound lead to the same location. The match is done
       lexically and must fit exactly.  An exception is,  when  the  name  pattern  is  given  as
       network path name as in atnetwork(3). A network pathname consists of the name of the host,
       controlling the device where a version is stored, the canonical pathname  to  the  version
       and  a version binding (e.g. version number, version alias, or date) either in brackets or
       separated from the name by an at (@) sign. Examples are

           desaster:/usr/sample/project/foo.c[1.0];
           desaster:/usr/sample/project/variant1/bar.c[var1-1.4];
           desaster:/usr/sample/project/xyyz.h@1.3;
           desaster:/usr/sample/project/bar.c@Fri Jun 18 13:40:58 MET DST 1993.

       Network pathnames are mapped to canonical local pathnames before being  processes  and  in
       this case, the given name to be bound will also be mapped to a canonical local pathname.

       The  technique  using  network pathnames is especially useful when storing the result of a
       successful version selection  persistently.   This  makes  the  version  selection  easily
       reproducible  from  anywhere in the local areas network. shape(1) uses this mechanism when
       generating its bound configuration threads.

PREDICATES

       This is the complete list of valid predicate names and a synopsis of their arguments.  The
       list is divided into several parts, each describing a certain class of predicates.

       The  first  class  are predicates working independently on each element of the current hit
       set. They impose certain requirements to the attributes  of  each  version  and  eliminate
       those, not fulfilling the requirements.

       eq (attrName,attrValue)
              The  named  attribute  must  exist  in the versions attribute list and it must have
              exactly the given value. When the  corresponding  version  attribute  has  multiple
              values, at least one of the values must match exactly.

       hasattr (attrName)
              The  named  attribute must exist in the versions attribute list.  When applied to a
              standard attribute, hasattr requires a value to be  associated  with  the  standard
              attribute. In case of user defined attributes, the attribute value is not regarded.

       ne (attrName,attrValue)
              The  named attribute, when existing in the versions attribute buffer, must not have
              the given attribute value. When the attribute does not exist, everything  is  fine.
              If  the  attribute  has  multiple  values,  it is required, that none of the values
              matches the given attrValue.

       {ge,gt,le,lt} (attrName,attrValue)
              The named version attribute must have a value, that is greater or equal  /  greater
              than  /  less  or  equal / less than the given attribute value. The named attribute
              must exist in the versions attribute buffer, otherwise the  version  is  eliminated
              from  the hit set. For attributes with multiple values, only one of the values must
              meet the required property.

       The second class are predicates that do not operate on single version but  rather  on  the
       complete  hit  set.  They  express relations between different versions in the hit set and
       base their selection on comparison of different versions.  Usually, they are used to get a
       unique version binding, by ordering the hit set and selecting one of the extremes.

       min (attrName)
              Retain the version(s) with the lowest value for the named attribute in the hit set.
              String values are compared literally, others "naturally" (see  the  list  of  known
              attributes  below  for  an  explanation  of that).  Versions not carrying the named
              attribute or having no value associated with the attribute name are eliminated from
              the hit set.

       max (attrName)
              Retain  the  version(s)  with  the highest value for the named attribute in the hit
              set. String values are compared literally, others  "naturally"  (see  the  list  of
              known  attributes  below  for  an  explanation of that).  Versions not carrying the
              named attribute  or  having  no  value  associated  with  the  attribute  name  are
              eliminated from the hit set.

       The  next  two  predicate  groups  have  no  direct  influence  on  the hit set.  They can
       invalidate the hit set and cause the rule evaluation to go  on  with  the  next  attribute
       expression, but they do never modify the hit set. These predicates are activated, when the
       evaluation of the attribute expression reaches them, i.e. when the hit set is not empty.

       msg (msgString)
              Print the given message to standard output and retain the current hit set.

       cut (msgString)
              Force the current rule binding to fail and print  the  given  message  to  standard
              output.  Printing  is omitted, when the message string is empty. Rule processing is
              stopped immediately and the returned hit set is empty.

       confirm (msgString,expectedAnswer)
              Ask the user for confirmation to go on with the evaluation of the current attribute
              expression.  The  given  message  string  is  printed  to  standard output with the
              expected answer appended in square brackets.  After that, user input is read.  When
              the  user  confirms  the expected answer (empty input) or his/her input matches the
              expected  answer,  evaluation  of  the  current  attribute  expression   continues.
              Otherwise,  the current hit set is invalidated and processing goes on with the next
              attribute expression.

       bindrule (ruleName)
              Abort evaluation of current attribute expression and switch to another version bind
              rule. This predicate makes only sense as last predicate in an attribute expression,
              as following predicates will never be evaluated.  Evaluation  of  the  target  rule
              (ruleName)  happens  as  if the rule has been invoked directly, no influence on the
              initial hit set is taken. When the target  rule  fails,  the  evaluation  algorithm
              switches back to the source rule and goes on with the next attribute expression.

       The  last  predicate  group  are  external  constraints.  Their  task  is to influence the
       evaluation process by examining conditions outside the handled version  history.  Each  of
       the following predicates has either a positive or a negative result. Positive results have
       no effect on the hit set and the evaluation process, while negative results invalidate the
       hit set and cause evaluation to go on with the next attribute expression.

       exists (name[binding])
              Version  binding  with  the given name (usually another one than the current target
              name) and the given version binding must lead to at least one version.  The  result
              is not required to be unique.

       existsnot (name[binding])
              Version binding with the given name and rule must fail.

       existsuniq (name[binding])
              Version binding with the given name and rule must lead to a unique selection.

       condexpr (program,expression)
              An  external  program,  named in the program argument, is activated to evaluate the
              given expression. The expression string is written to the  standard  input  of  the
              external  program.  A  zero  result  code  is considered to be positive, all others
              negative.

OBSOLETE PREDICATE NAMES

       There are a number of known predicate  names  from  former  versions  of  the  bind  rules
       machinery. They are internally mapped to the new predicate names. These names are obsolete
       and should not be used any longer.

       Obsolete   name   mapped    to    -   cut    attr            eq    attrex          hasattr
       attrge          ge      attrgt          gt      attrle          le      attrlt          lt
       attrmax         max    attrmin         min    attrnot         ne    condex          exists
       condnot         existsnot conduniq        existsuniq

ATTRIBUTES

       All  predicates  with  effect  on  the contents of the hit set work on version attributes.
       These attributes are either standard attributes with a defined  meaning  or  user  defined
       attributes.  The following is a list of attribute names recognized as standard attributes.
       All other names are considered to be user defined attributes.

       alias      Version alias name (symbolic version identification name).

       atime      The date of last access (read or write) to the versions contents.

       author     The version author in the form username@domain.

       cachekey   A unique key for cached versions built from the creation date, the  id  of  the
                  creating process and a serial number (e.g.  740148430.18469.6).

       ctime      The  date of the last status change. This date is updated, when an attribute is
                  added or deleted, or an attribute value is changed.

       generation
                  The generation number. The value for this attribute is plain numeric.

       host       The name of the host from where the version was accessed.  This  attribute  may
                  have  different values at one time, when the version is accessed from different
                  hosts.

       locker     The user who has set a lock on the concerned version.  This  attribute  has  an
                  empty  value,  when no lock is active. The attribute value is given in the form
                  username@domain.

       ltime      The date of last lock change (set or give up update lock). This  has  an  empty
                  value is empty, when there was never a lock set on the version.

       mtime      The date of the last modification of the versions contents.

       name       The name (without suffix) of the version. For example foo for foo.c.

       owner      The version owner in the form username@domain.

       revision   The revision number. As for generation, only numeric values are accepted.

       size       The size of the versions contents in bytes.

       status     The  version status. This is one of busy, saved, proposed, published, accessed,
                  or frozen.

       stime      The save date. This attribute has an empty value for busy versions.

       syspath    The absolute pathname through which the version was  accessed.  This  attribute
                  may  have  different  values  at  one  time,  when  the  version is accessed by
                  different pathnames (e.g. symbolic links).

       type       The suffix part of the versions name. For example fc for foo.c.

       version    The version number in the form generation.revision.  A  special  value  is  the
                  string  busy  instead  of  a  version  number. As busy versions have no version
                  number, this value is used for identifying the busy version of a history.

       Some predicates (like ge or  max)  require  an  ordering  relationship  between  attribute
       values.  For user defined attributes, ordering bases on alphabetical (ASCII) comparison of
       the values. User defined attributes with multiple  values  are  compared  by  their  first
       values,  if  these  are identical by their second values and so on. No value is considered
       smaller than any other value. For example

               attr1 = anton                  attr2 = berta
                       berta   is smaller than        anton
                       karl

       but
               attr1 = anton                  attr2 = anton
                       berta   is bigger than         berta
                       karl

       For some of the standard attributes listed above, we need special
       regulations.

       Version numbers (generation.revision)
                  are ordered by generation number first and revision number secondary
                  (e.g. 1.2 is smaller than 2.1). Busy is smaller than
                  any version number.

       Alias Names
                  are ordered by the version numbers (see above) of the identified
                  versions.

       Cache keys are ordered by simple text comparison. This has the effect that the
                  youngest cache key is considered the biggest.

       Version states
                  are ordered in the sequence as listed above. Busy is the lowest
                  and frozen the highest state.

       User attributes
                  The order of user attributes bases on alphabetical comparison of the
                  string username@domain.

       Time attributes
                  Time comparison assumes older dates to be smaller than newer ones.

EXPANSION

       During evaluation of version bind rules, four different kinds of expansion  are  possible.
       These  are   parameter  substitution,  attribute  expansion,  external macro expansion and
       command substitution. Expansion happens, when a magic pattern is found in the  rule  text,
       starting  with  either  a  dollar  sign  ($)  or,  in case of command substitution, with a
       backward quote character (`).

       Generally, expansion in version  bind  rules  happens  only  within  patterns  and  within
       predicate  arguments.  Bind  rule  syntax  or  predicate  names  cannot  be  introduced by
       substituted strings.  Expansions outside patterns and predicate arguments are ignored  and
       usually lead to an error message.

   Parameter Substitution
       A  parameter  substitution  string is usually introduced by the pattern $_ followed by the
       parameter name (an exception is $+ as shown  below).  The  parameter  name  is  optionally
       delimited  by  a  dollar  sign.  This  is necessary, when there is no whitespace character
       following. The parameter name may be any of the names specified in the rule head or one of
       the following predefined names.

       $_rule$       The current rule name.

       $_target$ or $+
                     The current target file name to be bound.

       $_parameter$  Any other parameter.

       A  parameter may have the same name as a citeable attribute (see below). In this case, the
       parameter citation hides the attribute citation. There is no way to cite the value  of  an
       attribute  when there is an equally named rule parameter. The reserved names rule, target,
       and hits are not allowed as parameter names.

   Attribute Expansion
       An attribute expansion string looks exactly like a parameter substitution  string.  It  is
       introduced  by the pattern $_ followed by the attribute name which is optionally delimited
       by a dollar sign, when a non-whitespace character follows immediately. Attribute names may
       be  built  of  any  printable  characters  except '#'.  Besides, it makes no sense to cite
       attributes with an equal sign ('=') in the attribute name, as  the  Attributed  Filesystem
       (AtFS) doesn't allow this.

       The  value by which the attribute expansion string will be replaced depends on the current
       state of processing. This may cause different values to be inserted for the same  citation
       in  different  processing  states.  Attribute expansion happens as late as possible, it is
       done right before the  evaluation  of  the  concerned  pattern  or  predicate.   With  one
       exception,  $_hits$, attribute expansions will only be substituted, if the current hit set
       cardinality is 1.

       $_hits$ or $=
                     The number of versions satisfying the binding conditions  expressed  so  far
                     (the  cardinality  of  the  hit set). This value continuously changes during
                     rule evaluation.

       $_attribute$  The value of any attribute of a uniquely selected version.

       Attribute citations may be overloaded by parameter citations (see above).

   External Macro Expansion
       External macros are evaluated by an external macro processor. If no such  macro  processor
       is available, external macros remain unchanged.  They have the form:

       $C     where C is any printable non-whitespace character except '+', '=', '_', ':', or '#'

       $(macroName) or ${macroName}
              Macro names may not contain '#' characters. Other limitations may be imposed by the
              external macro definition and processing facility.

   Command Substitution
       A command enclosed in back quotes occuring in a bind rule quotes will be replaced  by  its
       output.  No  modifications  are  done  to the command output, hence it may contain newline
       characters.

LEXICAL STRUCTURE

       There are some characters with special meaning when occurring in version bind rules. These
       are  the  syntactical  characters  colon  (:),  comma, (,), semicolon (;), period (.), and
       parentheses (( and )), the comment symbol (#), the dollar sign ($) or the back  quote  (`)
       introducing expansion strings ($), quotes (" and '), and the escape symbol (\).

       Comments  are  handled somewhat rigorously. A comment symbol (#) occurring anywhere in the
       rule name or rule body has effect as long  as  it  is  not  escaped  by  a  backslash  (\)
       character.  Comments  range  from  the  comment symbol (inclusive) to the end of the line.
       Newline characters  within  comments  may  also  be  escaped  by  a  backslash  character,
       continuing the comment on the next line.

       Nesting of parentheses and quotes is not supported.

       The following is a list of lexical constraints for each part of a version bind rule.

       Rule names and rule parameters
               Rule  names may consist of any printable non-whitespace character except colon and
               parentheses. The leftmost colon or opening parentheses delimits the rule name.
               Rule parameter names follow the same  lexical  rule,  but  additionally  must  not
               contain comma characters, as this in the delimiter between parameters.

       Patterns
               In  principle,  name  patterns  may consist of any printable character.  Comma and
               semicolon characters occurring in a name pattern must be escaped  by  a  backslash
               character. A period occurring in a name pattern needs not to be escaped as long as
               it is not the last character (ignoring trailing  whitespace)  in  the  rule  body.
               Period  as  last  character  is  always  considered  to be end of rule sign.  Name
               patterns may contain macro or parameter citations and command substitutions.

       Predicates
               Each predicate name must be one of the reserved names listed  previously  in  this
               paper.   Predicate   arguments   consist  of  any  printable  character  including
               whitespace. Comma, parenthesis or quoting characters must be escaped. Any argument
               may be quoted by single or double quotes. Quoting exceeds line limits.
               Predicate  arguments may contain macro, attribute or parameter citations leaded by
               a dollar sign, or command substitutions enclosed in back quotes.  When  quoted  in
               single  quotes, dollar signs and back quotes occurring in a predicate argument are
               not taken by their special meaning and no citations happen. Double quotes  do  not
               hide citations.

TIPS, TRICKS, AND TRAPS

       Why  doesn't  the  bind rule select version xyz although I think it should ?. An important
       facility to find an answer to this question is the trace option provided by  the  vbind(1)
       command. It shows the evolution of the hit set during rule evaluation.

       Typing errors in standard attribute names may lead to confusing situations. They cannot be
       recognized by the evaluation machinery, as any unknown attribute name is considered to  be
       an user defined attribute.

       A minus sign (-) as first character in an alternative is considered as part of the pattern
       and not as (old style) cut operator.  Hence
               -; (- as pattern)
       and
               ,-; (default pattern followed by cut)
       make a big difference. We recommend the use of cut() in any case. The short  form  (-)  is
       supported only for compatibility with older versions.

GRAMMAR

       bind_rule ::= bind_rule_head :[-] bind_rule_body .

       bind_rule_head ::= rule_name | rule_name ( rule_arg_list ) .

       rule_arg_list: rule_name { , arg_name }* .

       bind_rule_body ::= attr_expression { ; attr_expression}* . .

       attr_expression ::=name_pattern { , predicate }* |
                        predicate { , predicate }* | .

       name_pattern ::= { <any printable character or whitespace> }+

       predicate ::=   attr_value_predicate ( attr_name , string ) |
                attr_name_predicate ( attr_name ) |
                bind_rule_predicate ( rule_name ) |
                msg_predicate ( string ) |
                msg_answer_predicate ( string , string ) |
                cond_rule_predicate ( string , bind_rule_head ) |
                cond_expr_predicate ( string , string ) |
                cut_predicate.

       attr_value_predicate ::= eq | ge | gt | le | lt | ne .

       attr_name_predicate ::= hasattr | max | min .

       bind_rule_predicate ::= bindrule .

       msg_predicate ::= cut | msg .

       msg_answer_predicate ::= confirm .

       cond_rule_predicate ::= exists | existsnot | existsuniq .

       cond_expr_predicate ::= condexpr .

       cut_predicate ::= - .

       attr_name ::=   arg_name | author | atime | ctime | generation |
                       locker | ltime | mtime | owner |
                       revision | size | state | stime | version .

       rule_name ::= { <any printable character except colon and parentheses }+ .

       arg_name ::= { <any printable character except comma, colon and parentheses }+ .

       string ::= { <any printable character or whitespace> } .

FILES

       $SHAPETOOLS/BindRules

SEE ALSO

       vbind(1), vadm(1), atnetwork(3), shape(1)

AUTHOR

       Andreas.Lampen@cs.tu-berlin.de