Define Equivalences for File Names

For example:

• Instruct the server to parse the equiv.tcl file and provide entries to clients. This is the default behavior. Note that for this case, equivalences that reference an environment variable should not resolve the variable in this file, in environments that will have both UNIX and Windows clients. Instead, they will need to be resolved by the client upon receipt. This is done by enclosing the equivalence value inside curly braces and referring the environment variable as $VARNAME as opposed to the Tcl format of $env(VARNAME).
• Instruct clients to read the file directly. This is a legacy method that requires that all clients have access to the server working directory so they can parse the equiv.tcl file for entries, and read/write access to the equiv.caches directory so the entries can be written to a host-based cache file for future use. In this mode, environment variables may be resolved in this file, but the behavior will be the same as not allowing them to be resolved. To resolve them in this file, the equivalence value should not be wrapped with curly braces and the environment variable should be referred to in the Tcl format of $env(VARNAME). This method is enabled by setting the VOVEQUIV_CACHE_FILE environment variable to "legacy".
• Instruct clients to read a specific cache file only. This is a special method used in corner cases where directories may not be the same but should be forced to be considered the same. This is utilized mainly by Monitor agent single-file distributables. In this mode, environment variables may be resolved in this file, but the behavior will be the same as not allowing them to be resolved. To resolve them in this file, the equivalence value should not be wrapped with curly braces and the environment variable should be referred to in the Tcl format of $env(VARNAME). This method is enabled by setting the VOVEQUIV_CACHE_FILE environment variable to a valid equivalence cache file path.

The procedure vtk_equivalence has the following purposes:

• The main purpose is to define an equivalence between a logical name and a physical path, as in:

  vtk_equivalence TOP /export/projects/cpu
  vtk_equivalence TOP p:/cpu

  Note: The physical path need not be canonical. The definition is silently ignored if the physical path does not exist.
• The secondary purpose is to control the case sensitivity for file names, using the options -nocase or -case. With -nocase, all names are canonicalized to lowercase, which is useful when the vovserver is running on a Windows NT machine.
• The third purpose is to control whether the AFS paths should be supported. If the -afs option is used, then all paths of the type /.automount/hostname1/root/aaa become /net/hostname1/aaaa

The procedure vtk_equivalence also has side effects:

• The environment variable corresponding to the logical name is set, if it does not exist already (that is, the variable $env(TOP)).
• The Tcl global variable corresponding to the logical name is set to the value of the environment variable (that is, the variable $TOP).

See the following example:

# -- HOME should not be used in multi-user projects, because it has a
# -- different value for each user. Use it only in single-user projects.

vtk_equivalence HOME $env(HOME)

# -- VOVDIR is always defined and these equivalences are always useful.

vtk_equivalence VOVDIR $VOVDIR
vtk_equivalence VOVDIR $VOVDIR/../common

# -- Data directories.

vtk_equivalence TOP /export/projects/cpu; # This is for Unix
vtk_equivalence TOP p:/cpu              ; # This is for Windows

# Uncomment this if you need AFS paths.

# vtk_equivalence -afs

The server-side equivalence cache can be set with via the VTK Tcl API using vtk_equivalence_set_cache HOSTNAME VALUES, where HOSTNAME is the name of a host or the "_default_", and VALUES is a Tcl list with an even number of elements in the form LOGICAL_NAME PHYSICAL_PATH.

vtk_equivalence_set_cache lin0201 "HOMES /homes VOVDIR /tmp_mnt/tools/rtda/current/"