Ulf Wiger etxuwig@REDACTED
Thu Dec 6 10:39:43 CET 2001

On Wed, 5 Dec 2001, Vance Shipley wrote:

>	priv_dir(Name) -> PrivDir | {error, What}
>	This function returns the current priv directory for the
>	Name[-*] directory. The current path is searched for a
>	directory named .../Name-* (the -* suffix is optional for
>	directories in the search path and it represents the version
>	of the directory). The /priv suffix is added to the end of
>	the found directory.

This description is not consistent with how it's actually
implemented. The path is _not_searched when priv_dir/1 is called.
Rather, when add_path/1 is called, the path to the Name[-*]
directory is stored in a code_names table. The call to
priv_dir(Name) will result in a lookup on that table; if Name
does not exist there, {error, ...} is returned; otherwise, /priv
is appended. No check is made to verify that Name/priv actually
exists (which is as it should be). On the other hand, when
code:add_path/1 is called, the supplied paths _are_ verified.

There is a reason for this disparity. Originally, priv_dir/1
_was_ implemented as described in the manual. However, it is
sometimes quite useful to call priv_dir frequently. For example,
we store HTML code under a certain priv_dir, allowing us to have
the HTML code easily (automatically) upgraded. Searching the full
code path every time priv_dir() was to be resolved was less than
optimal, and users of priv_dir() shouldn't have to worry about
the cost, and perhaps create ugly workarounds.

There is no logical way to add a name to the code_names table
except calling code:add_path(Name ++ "/ebin"). This is where the
compiled code should reside. There is no code:add_name/1
function (I'm not necessarily saying that there should be.)

Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks

More information about the erlang-questions mailing list