path: root/lib/kernel/doc/src/code.xml

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd">

<erlref>
  <header>
    <copyright>
      <year>1996</year><year>2013</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      Licensed under the Apache License, Version 2.0 (the "License");
      you may not use this file except in compliance with the License.
      You may obtain a copy of the License at
 
          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
      See the License for the specific language governing permissions and
      limitations under the License.
    
    </legalnotice>

    <title>code</title>
    <prepared></prepared>
    <docno></docno>
    <date></date>
    <rev></rev>
  </header>
  <module>code</module>
  <modulesummary>Erlang Code Server</modulesummary>
  <description>
    <p>This module contains the interface to the Erlang
      <em>code server</em>, which deals with the loading of compiled
      code into a running Erlang runtime system.</p>
    <p>The runtime system can be started in either <em>embedded</em> or
      <em>interactive</em> mode. Which one is decided by the command
      line flag <c>-mode</c>.</p>
    <pre>
% <input>erl -mode interactive</input></pre>
    <p>Default mode is <c>interactive</c>.</p>
    <list type="bulleted">
      <item>
        <p>In embedded mode, all code is loaded during system start-up
          according to the boot script. (Code can also be loaded later
          by explicitly ordering the code server to do so).</p>
      </item>
      <item>
        <p>In interactive mode, only some code is loaded during system
          startup-up, basically the modules needed by the runtime
          system itself. Other code is dynamically loaded when first
          referenced. When a call to a function in a certain module is
          made, and the module is not loaded, the code server searches
          for and tries to load the module.</p>
      </item>
    </list>
    <p>To prevent accidentally reloading modules affecting the Erlang
      runtime system itself, the <c>kernel</c>, <c>stdlib</c> and
      <c>compiler</c> directories are considered <em>sticky</em>. This
      means that the system issues a warning and rejects the request if
      a user tries to reload a module residing in any of them.
      The feature can be disabled by using the command line flag
      <c>-nostick</c>.</p>
  </description>

  <section>
    <title>Code Path</title>
    <p>In interactive mode, the code server maintains a search path --
      usually called the <em>code path</em> -- consisting of a list of
      directories, which it searches sequentially when trying to load a
      module.</p>
    <p>Initially, the code path consists of the current working
      directory and all Erlang object code directories under the library
      directory <c>$OTPROOT/lib</c>, where <c>$OTPROOT</c> is
      the installation directory of Erlang/OTP, <c>code:root_dir()</c>.
      Directories can be named <c>Name[-Vsn]</c> and the code server,
      by default, chooses the directory with the highest version number
      among those which have the same <c>Name</c>. The <c>-Vsn</c>
      suffix is optional. If an <c>ebin</c> directory exists under
      <c>Name[-Vsn]</c>, it is this directory which is added to
      the code path.</p>
    <p>The environment variable <c>ERL_LIBS</c> (defined in the operating
      system) can be used to define additional library directories that
      will be handled in the same way as the standard OTP library
      directory described above, except that directories that do not
      have an <c>ebin</c> directory will be ignored.</p>
    <p>All application directories found in the additional directories
      will appear before the standard OTP applications, except for the
      Kernel and STDLIB applications, which will be placed before any
      additional applications. In other words, modules found in any
      of the additional library directories will override modules with
      the same name in OTP, except for modules in Kernel and
      STDLIB.</p>
    <p>The environment variable <c>ERL_LIBS</c> (if defined) should contain
      a colon-separated (for Unix-like systems) or semicolon-separated
      (for Windows) list of additional libraries.</p>
    <p>Example: On an Unix-like system, <c>ERL_LIBS</c> could be set to
      <c>/usr/local/jungerl:/home/some_user/my_erlang_lib</c>. (On Windows,
      use semi-colon as separator.)</p>
  </section>

  <section>
    <title>Loading of Code From Archive Files</title>

    <warning><p>The support for loading of code from archive files is
     experimental. The sole purpose of releasing it before it is ready
     is to obtain early feedback. The file format, semantics,
     interfaces etc. may be changed in a future release. The function
     <c>lib_dir/2</c> and the flag <c>-code_path_choice</c> are also
     experimental.</p></warning>

    <p>In the current implementation, Erlang archives are <c>ZIP</c>
     files with <c>.ez</c> extension. Erlang archives may also be
     enclosed in <c>escript</c> files whose file extension is arbitrary.</p>

    <p>Erlang archive files may contain entire Erlang applications or
     parts of applications. The structure in an archive file is the
     same as the directory structure for an application. If you for
     example would create an archive of <c>mnesia-4.4.7</c>, the
     archive file must be named <c>mnesia-4.4.7.ez</c> and it must
     contain a top directory with the name <c>mnesia-4.4.7</c>. If the
     version part of the name is omitted, it must also be omitted in
     the archive. That is, a <c>mnesia.ez</c> archive must contain a
     <c>mnesia</c> top directory.</p>

    <p>An archive file for an application may for example be
     created like this:</p>

<pre>
   zip:create("mnesia-4.4.7.ez", 
              ["mnesia-4.4.7"], 
              [{cwd, code:lib_dir()},
               {compress, all},
               {uncompress,[".beam",".app"]}]).</pre>

    <p>Any file in the archive may be compressed, but in order to
     speed up the access of frequently read files, it may be a good
     idea to store <c>beam</c> and <c>app</c> files uncompressed in
     the archive.</p>

    <p>Normally the top directory of an application is located either
     in the library directory <c>$OTPROOT/lib</c> or in a directory
     referred to by the environment variable <c>ERL_LIBS</c>. At
     startup when the initial code path is computed, the code server
     will also look for archive files in these directories and
     possibly add <c>ebin</c> directories in archives to the code path. The
     code path will then contain paths to directories that looks like
     <c>$OTPROOT/lib/mnesia.ez/mnesia/ebin</c> or
     <c>$OTPROOT/lib/mnesia-4.4.7.ez/mnesia-4.4.7/ebin</c>.</p>

    <p>The code server uses the module <c>erl_prim_loader</c>
     (possibly via the <c>erl_boot_server</c>) to read code files from
     archives. But the functions in <c>erl_prim_loader</c> may also be
     used by other applications to read files from archives. For
     example, the call
     <c>erl_prim_loader:list_dir( "/otp/root/lib/mnesia-4.4.7.ez/mnesia-4.4.7/examples/bench)"</c>
     would list the contents of a directory inside an archive.
     See <seealso marker="erts:erl_prim_loader">erl_prim_loader(3)</seealso>.</p>

    <p>An application archive file and a regular application directory
     may coexist. This may be useful when there is a need of having
     parts of the application as regular files. A typical case is the
     <c>priv</c> directory which must reside as a regular directory in
     order to be able to dynamically link in drivers and start port
     programs. For other applications that do not have this need, the
     <c>priv</c> directory may reside in the archive and the files
     under the <c>priv</c> directory may be read via the
     <c>erl_prim_loader</c>.</p>

    <p>At the time point when a directory is added to the code path as
     well as when the entire code path is (re)set, the code server
     will decide which subdirectories in an application that shall be
     read from the archive and which that shall be read as regular
     files. If directories are added or removed afterwards, the file
     access may fail if the code path is not updated (possibly to the
     same path as before in order to trigger the directory resolution
     update). For each directory on the second level (ebin, priv, src
     etc.) in the application archive, the code server will firstly
     choose the regular directory if it exists and secondly from the
     archive. The function
     <c>code:lib_dir/2</c> returns the path to the subdirectory. For
     example <c>code:lib_dir(megaco,ebin)</c> may return
     <c>/otp/root/lib/megaco-3.9.1.1.ez/megaco-3.9.1.1/ebin</c> while
     <c>code:lib_dir(megaco,priv)</c> may return
     <c>/otp/root/lib/megaco-3.9.1.1/priv</c>.</p>

    <p>When an <c>escript</c> file contains an archive, there are
     neither restrictions on the name of the <c>escript</c> nor on how
     many applications that may be stored in the embedded
     archive. Single <c>beam</c> files may also reside on the top
     level in the archive. At startup, both the top directory in the
     embedded archive as well as all (second level) <c>ebin</c>
     directories in the embedded archive are added to the code path.
     See <seealso marker="erts:escript">escript(1)</seealso></p>

    <p>When the choice of directories in the code path is
     <c>strict</c>, the directory that ends up in the code path will
     be exactly the stated one. This means that if for example the
     directory <c>$OTPROOT/lib/mnesia-4.4.7/ebin</c> is explicitly
     added to the code path, the code server will not load files from
     <c>$OTPROOT/lib/mnesia-4.4.7.ez/mnesia-4.4.7/ebin</c> and vice
     versa. </p>

    <p>This behavior can be controlled via the command line flag
     <c>-code_path_choice Choice</c>. If the flag is set to <c>relaxed</c>,
     the code server will instead choose a suitable directory
     depending on the actual file structure. If there exists a regular
     application ebin directory, it will be chosen. But if it does
     not exist, the ebin directory in the archive is chosen if it
     exists. If neither of them exists the original directory will be
     chosen.</p>

    <p>The command line flag <c>-code_path_choice Choice</c> does also
     affect how <c>init</c> interprets the <c>boot script</c>. The
     interpretation of the explicit code paths in the <c>boot
     script</c> may be <c>strict</c> or <c>relaxed</c>. It is
     particular useful to set the flag to <c>relaxed</c> when you want
     to elaborate with code loading from archives without editing the
     <c>boot script</c>. The default is <c>relaxed</c>. See <seealso
     marker="erts:init">init(3)</seealso></p></section>

  <section>

    <title>Current and Old Code</title>
    <p>The code of a module can exists in two variants in a system:
      <em>current code</em> and <em>old code</em>. When a module is
      loaded into the system for the first time, the code of the module
      becomes 'current' and the global <em>export table</em> is updated
      with references to all functions exported from the module.</p>
    <p>If then a new instance of the module is loaded (perhaps because
      of the correction of an error), then the code of the previous
      instance becomes 'old', and all export entries referring to
      the previous instance are removed. After that the new instance is
      loaded as if it was loaded for the first time, as described above,
      and becomes 'current'.</p>
    <p>Both old and current code for a module are valid, and may even be
      evaluated concurrently. The difference is that exported functions
      in old code are unavailable. Hence there is no way to make a
      global call to an exported function in old code, but old code may
      still be evaluated because of processes lingering in it.</p>
    <p>If a third instance of the module is loaded, the code server will
      remove (purge) the old code and any processes lingering in it will
      be terminated. Then the third instance becomes 'current' and
      the previously current code becomes 'old'.</p>
    <p>For more information about old and current code, and how to
      make a process switch from old to current code, refer to
      <seealso marker="doc/reference_manual:code_loading">Erlang Reference Manual</seealso>.</p>
  </section>

  <section>
    <title>Argument Types and Invalid Arguments</title>

    <p>Generally, module and application names are atoms, while file and directory
    names are strings. For backward compatibility reasons, some functions accept
    both strings and atoms, but a future release will probably only allow
    the arguments that are documented.</p>

    <p>From the R12B release, functions in this module will generally fail with an
    exception if they are passed an incorrect type (for instance, an integer or a tuple
    where an atom was expected). An error tuple will be returned if the type of the argument
    was correct, but there was some other error (for instance, a non-existing directory
    was given to <c>set_path/1</c>).</p>
  </section>

  <datatypes>
    <datatype>
      <name name="load_ret"/>
    </datatype>
    <datatype>
      <name name="load_error_rsn"/>
    </datatype>
  </datatypes>

  <funcs>
    <func>
      <name name="set_path" arity="1"/>
      <fsummary>Set the code server search path</fsummary>
      <desc>
        <p>Sets the code path to the list of directories <c><anno>Path</anno></c>.</p>
        <p>Returns <c>true</c> if successful, or
          <c>{error, bad_directory}</c> if any <c><anno>Dir</anno></c> is not
          the name of a directory, or <c>{error, bad_path}</c> if
          the argument is invalid.</p>
      </desc>
    </func>
    <func>
      <name name="get_path" arity="0"/>
      <fsummary>Return the code server search path</fsummary>
      <desc>
        <p>Returns the code path</p>
      </desc>
    </func>
    <func>
      <name name="add_path" arity="1"/>
      <name name="add_pathz" arity="1"/>
      <fsummary>Add a directory to the end of the code path</fsummary>
      <type name="add_path_ret"/>
      <desc>
        <p>Adds <c><anno>Dir</anno></c> to the code path. The directory is added as
          the last directory in the new path. If <c><anno>Dir</anno></c> already
          exists in the path, it is not added.</p>
        <p>Returns <c>true</c> if successful, or
          <c>{error, bad_directory}</c> if <c><anno>Dir</anno></c> is not the name
          of a directory.</p>
      </desc>
    </func>
    <func>
      <name name="add_patha" arity="1"/>
      <fsummary>Add a directory to the beginning of the code path</fsummary>
      <type name="add_path_ret"/>
      <desc>
        <p>Adds <c><anno>Dir</anno></c> to the beginning of the code path. If
          <c><anno>Dir</anno></c> already exists, it is removed from the old
          position in the code path.</p>
        <p>Returns <c>true</c> if successful, or
          <c>{error, bad_directory}</c> if <c><anno>Dir</anno></c> is not the name
          of a directory.</p>
      </desc>
    </func>
    <func>
      <name name="add_paths" arity="1"/>
      <name name="add_pathsz" arity="1"/>
      <fsummary>Add directories to the end of the code path</fsummary>
      <desc>
        <p>Adds the directories in <c><anno>Dirs</anno></c> to the end of the code
          path. If a <c><anno>Dir</anno></c> already exists, it is not added. This
          function always returns <c>ok</c>, regardless of the validity
          of each individual <c><anno>Dir</anno></c>.</p>
      </desc>
    </func>
    <func>
      <name name="add_pathsa" arity="1"/>
      <fsummary>Add directories to the beginning of the code path</fsummary>
      <desc>
        <p>Adds the directories in <c><anno>Dirs</anno></c> to the beginning of
          the code path. If a <c><anno>Dir</anno></c> already exists, it is removed
          from the old position in the code path. This function always
          returns <c>ok</c>, regardless of the validity of each
          individual <c><anno>Dir</anno></c>.</p>
      </desc>
    </func>
    <func>
      <name name="del_path" arity="1"/>
      <fsummary>Delete a directory from the code path</fsummary>
      <desc>
        <p>Deletes a directory from the code path. The argument can be
          an atom <c><anno>Name</anno></c>, in which case the directory with
          the name <c>.../<anno>Name</anno>[-Vsn][/ebin]</c> is deleted from the code
          path. It is also possible to give the complete directory name
          <c><anno>Dir</anno></c> as argument.</p>
        <p>Returns <c>true</c> if successful, or <c>false</c> if
          the directory is not found, or <c>{error, bad_name}</c> if
          the argument is invalid.</p>
      </desc>
    </func>
    <func>
      <name name="replace_path" arity="2"/>
      <fsummary>Replace a directory with another in the code path</fsummary>
      <desc>
        <p>This function replaces an old occurrence of a directory
          named <c>.../<anno>Name</anno>[-Vsn][/ebin]</c>, in the code path, with
          <c><anno>Dir</anno></c>. If <c><anno>Name</anno></c> does not exist, it adds the new
          directory <c><anno>Dir</anno></c> last in the code path. The new directory
          must also be named <c>.../<anno>Name</anno>[-Vsn][/ebin]</c>. This function
          should be used if a new version of the directory (library) is
          added to a running system.</p>
        <p>Returns <c>true</c> if successful, or
          <c>{error, bad_name}</c> if <c><anno>Name</anno></c> is not found, or
          <c>{error, bad_directory}</c> if <c><anno>Dir</anno></c> does not exist, or
          <c>{error, {badarg, [<anno>Name</anno>, <anno>Dir</anno>]}}</c> if <c><anno>Name</anno></c> or
          <c><anno>Dir</anno></c> is invalid.</p>
      </desc>
    </func>
    <func>
      <name name="load_file" arity="1"/>
      <fsummary>Load a module</fsummary>
      <type name="load_ret"/>
      <desc>
        <p>Tries to load the Erlang module <c><anno>Module</anno></c>, using
          the code path. It looks for the object code file with an
          extension that corresponds to the Erlang machine used, for
          example <c><anno>Module</anno>.beam</c>. The loading fails if the module
          name found in the object code differs from the name
          <c><anno>Module</anno></c>.
          <seealso marker="#load_binary/3">load_binary/3</seealso> must
          be used to load object code with a module name that is
          different from the file name.</p>
        <p>Returns <c>{module, <anno>Module</anno>}</c> if successful, or
          <c>{error, nofile}</c> if no object code is found, or
          <c>{error, sticky_directory}</c> if the object code resides in
          a sticky directory. Also if the loading fails, an error tuple is
          returned. See
          <seealso marker="erts:erlang#load_module/2">erlang:load_module/2</seealso>
          for possible values of <c><anno>What</anno></c>.</p>
      </desc>
    </func>
    <func>
      <name name="load_abs" arity="1"/>
      <fsummary>Load a module, residing in a given file</fsummary>
      <type name="load_ret"/>
      <type name="loaded_filename"/>
      <type name="loaded_ret_atoms"/>
      <desc>
        <p>Does the same as <c>load_file(<anno>Module</anno>)</c>, but
          <c><anno>Filename</anno></c> is either an absolute file name, or a
          relative file name. The code path is not searched. It returns
          a value in the same way as
          <seealso marker="#load_file/1">load_file/1</seealso>. Note
          that <c><anno>Filename</anno></c> should not contain the extension (for
          example <c>".beam"</c>); <c>load_abs/1</c> adds the correct
          extension itself.</p>
      </desc>
    </func>
    <func>
      <name name="ensure_loaded" arity="1"/>
      <fsummary>Ensure that a module is loaded</fsummary>
      <desc>
        <p>Tries to to load a module in the same way as
          <seealso marker="#load_file/1">load_file/1</seealso>,
	  unless the module is already loaded.
          In embedded mode, however, it does not load a module which is not
          already loaded, but returns <c>{error, embedded}</c> instead.</p>
      </desc>
    </func>
    <func>
      <name name="load_binary" arity="3"/>
      <fsummary>Load object code for a module</fsummary>
      <type name="loaded_filename"/>
      <type name="loaded_ret_atoms"/>
      <desc>
        <p>This function can be used to load object code on remote
          Erlang nodes. The argument <c><anno>Binary</anno></c> must contain
	  object code for <c><anno>Module</anno></c>.
          <c><anno>Filename</anno></c> is only used by the code server to keep a
          record of from which file the object code for <c><anno>Module</anno></c>
          comes. Accordingly, <c><anno>Filename</anno></c> is not opened and read by
          the code server.</p>
        <p>Returns <c>{module, <anno>Module</anno>}</c> if successful, or
          <c>{error, sticky_directory}</c> if the object code resides in
          a sticky directory, or <c>{error, badarg}</c> if any argument
          is invalid. Also if the loading fails, an error tuple is
          returned. See
          <seealso marker="erts:erlang#load_module/2">erlang:load_module/2</seealso>
          for possible values of <c><anno>What</anno></c>.</p>
      </desc>
    </func>
    <func>
      <name name="delete" arity="1"/>
      <fsummary>Removes current code for a module</fsummary>
      <desc>
        <p>Removes the current code for <c><anno>Module</anno></c>, that is,
          the current code for <c><anno>Module</anno></c> is made old. This means
          that processes can continue to execute the code in the module,
          but that no external function calls can be made to it.</p>
        <p>Returns <c>true</c> if successful, or <c>false</c> if there
          is old code for <c><anno>Module</anno></c> which must be purged first, or
          if <c><anno>Module</anno></c> is not a (loaded) module.</p>
      </desc>
    </func>
    <func>
      <name name="purge" arity="1"/>
      <fsummary>Removes old code for a module</fsummary>
      <desc>
        <p>Purges the code for <c><anno>Module</anno></c>, that is, removes code
          marked as old. If some processes still linger in the old code,
          these processes are killed before the code is removed.</p>
        <p>Returns <c>true</c> if successful and any process needed to
          be killed, otherwise <c>false</c>.</p>
      </desc>
    </func>
    <func>
      <name name="soft_purge" arity="1"/>
      <fsummary>Removes old code for a module, unless no process uses it</fsummary>
      <desc>
        <p>Purges the code for <c><anno>Module</anno></c>, that is, removes code
          marked as old, but only if no processes linger in it.</p>
        <p>Returns <c>false</c> if the module could not be purged due
          to processes lingering in old code, otherwise <c>true</c>.</p>
      </desc>
    </func>
    <func>
      <name name="is_loaded" arity="1"/>
      <fsummary>Check if a module is loaded</fsummary>
      <type name="loaded_filename"/>
      <type name="loaded_ret_atoms"/>
      <type_desc name="loaded_filename"><c><anno>Filename</anno></c> is an absolute filename</type_desc>
      <desc>
        <p>Checks if <c><anno>Module</anno></c> is loaded. If it is,
          <c>{file, <anno>Loaded</anno>}</c> is returned, otherwise <c>false</c>.</p>
        <p>Normally, <c><anno>Loaded</anno></c> is the absolute file name
          <c>Filename</c> from which the code was obtained. If the module
          is preloaded (see
          <seealso marker="sasl:script">script(4)</seealso>),
          <c>Loaded==preloaded</c>. If the module is Cover compiled (see
          <seealso marker="tools:cover">cover(3)</seealso>),
          <c>Loaded==cover_compiled</c>.</p>
      </desc>
    </func>
    <func>
      <name name="all_loaded" arity="0"/>
      <fsummary>Get all loaded modules</fsummary>
      <type name="loaded_filename"/>
      <type name="loaded_ret_atoms"/>
      <type_desc name="loaded_filename"><c><anno>Filename</anno></c> is an absolute filename</type_desc>
      <desc>
        <p>Returns a list of tuples <c>{<anno>Module</anno>, <anno>Loaded</anno>}</c> for all
          loaded modules. <c><anno>Loaded</anno></c> is normally the absolute file
          name, as described for
          <seealso marker="#is_loaded/1">is_loaded/1</seealso>.</p>
      </desc>
    </func>
    <func>
      <name name="which" arity="1"/>
      <fsummary>The object code file of a module</fsummary>
      <type name="loaded_ret_atoms"/>
      <desc>
        <p>If the module is not loaded, this function searches the code
          path for the first file which contains object code for
          <c><anno>Module</anno></c> and returns the absolute file name. If
          the module is loaded, it returns the name of the file which
          contained the loaded object code. If the module is pre-loaded,
          <c>preloaded</c> is returned. If the module is Cover compiled,
          <c>cover_compiled</c> is returned. <c>non_existing</c> is
          returned if the module cannot be found.</p>
      </desc>
    </func>
    <func>
      <name name="get_object_code" arity="1"/>
      <fsummary>Get the object code for a module</fsummary>
      <desc>
        <p>Searches the code path for the object code of the module
          <c><anno>Module</anno></c>. It returns <c>{<anno>Module</anno>, <anno>Binary</anno>, <anno>Filename</anno>}</c>
          if successful, and <c>error</c> if not. <c><anno>Binary</anno></c> is a
          binary data object which contains the object code for
          the module. This can be useful if code is to be loaded on a
          remote node in a distributed system. For example, loading
          module <c><anno>Module</anno></c> on a node <c>Node</c> is done as
          follows:</p>
        <code type="none">
...
{_Module, Binary, Filename} = code:get_object_code(Module),
rpc:call(Node, code, load_binary, [Module, Filename, Binary]),
...</code>
      </desc>
    </func>
    <func>
      <name name="root_dir" arity="0"/>
      <fsummary>Root directory of Erlang/OTP</fsummary>
      <desc>
        <p>Returns the root directory of Erlang/OTP, which is
          the directory where it is installed.</p>
        <pre>
> <input>code:root_dir().</input>
"/usr/local/otp"</pre>
      </desc>
    </func>
    <func>
      <name name="lib_dir" arity="0"/>
      <fsummary>Library directory of Erlang/OTP</fsummary>
      <desc>
        <p>Returns the library directory, <c>$OTPROOT/lib</c>, where
          <c>$OTPROOT</c> is the root directory of Erlang/OTP.</p>
        <pre>
> <input>code:lib_dir().</input>
"/usr/local/otp/lib"</pre>
      </desc>
    </func>
    <func>
      <name name="lib_dir" arity="1"/>
      <fsummary>Library directory for an application</fsummary>
      <desc>
        <p>This function is mainly intended for finding out the path
          for the "library directory", the top directory, for an
          application <c><anno>Name</anno></c> located under <c>$OTPROOT/lib</c> or
          on a directory referred to via the <c>ERL_LIBS</c>
          environment variable.</p>
        <p>If there is a regular directory called <c><anno>Name</anno></c> or
          <c><anno>Name</anno>-Vsn</c> in the code path with an <c>ebin</c>
          subdirectory, the path to this directory is returned (not
          the <c>ebin</c> directory). If the directory refers to a
          directory in an archive, the archive name is stripped away
          before the path is returned.  For example, if the directory
          <c>/usr/local/otp/lib/mnesia-4.2.2.ez/mnesia-4.2.2/ebin</c>
          is in the path, <c>/usr/local/otp/lib/mnesia-4.2.2/ebin</c>
          will be returned. This means that the library directory for
          an application is the same, regardless of whether the
          application resides in an archive or not.</p>

        <pre>
> <input>code:lib_dir(mnesia).</input>
"/usr/local/otp/lib/mnesia-4.2.2"</pre>
        <p>Returns <c>{error, bad_name}</c> if <c><anno>Name</anno></c>
	 is not the name of an application under <c>$OTPROOT/lib</c> or
	 on a directory referred to via the <c>ERL_LIBS</c>
         environment variable. Fails with an exception if <c>Name</c>
         has the wrong type.</p>

	<warning><p>For backward compatibility, <c><anno>Name</anno></c> is also allowed to
	be a string. That will probably change in a future release.</p></warning>
      </desc>
    </func>
    <func>
      <name name="lib_dir" arity="2"/>
      <fsummary>subdirectory for an application</fsummary>
      <desc>
        <p>Returns the path to a subdirectory directly under the top
         directory of an application. Normally the subdirectories
         resides under the top directory for the application, but when
         applications at least partly resides in an archive the
         situation is different. Some of the subdirectories may reside
         as regular directories while other resides in an archive
         file. It is not checked if this directory really exists.</p>

        <pre>
> <input>code:lib_dir(megaco, priv).</input>
"/usr/local/otp/lib/megaco-3.9.1.1/priv"</pre>

        <p>Fails with an exception if <c><anno>Name</anno></c> or <c><anno>SubDir</anno></c> has
        the wrong type.</p>
      </desc>
    </func>
    <func>
      <name name="compiler_dir" arity="0"/>
      <fsummary>Library directory for the compiler</fsummary>
      <desc>
        <p>Returns the compiler library directory. Equivalent to
          <c>code:lib_dir(compiler)</c>.</p>
      </desc>
    </func>
    <func>
      <name name="priv_dir" arity="1"/>
      <fsummary>Priv directory for an application</fsummary>
      <desc>
        <p>Returns the path to the <c>priv</c> directory in an
         application. Equivalent to <c>code:lib_dir(<anno>Name</anno>, priv).</c>.</p>

	<warning><p>For backward compatibility, <c><anno>Name</anno></c> is also allowed to
	be a string. That will probably change in a future release.</p></warning>
      </desc>
    </func>
    <func>
      <name name="objfile_extension" arity="0"/>
      <fsummary>Object code file extension</fsummary>
      <desc>
        <p>Returns the object code file extension that corresponds to
          the Erlang machine used, namely <c>".beam"</c>.</p>
      </desc>
    </func>
    <func>
      <name name="stick_dir" arity="1"/>
      <fsummary>Mark a directory as sticky</fsummary>
      <desc>
        <p>This function marks <c><anno>Dir</anno></c> as sticky.</p>
        <p>Returns <c>ok</c> if successful or <c>error</c> if not.</p>
      </desc>
    </func>
    <func>
      <name name="unstick_dir" arity="1"/>
      <fsummary>Remove a sticky directory mark</fsummary>
      <desc>
        <p>This function unsticks a directory which has been marked as
          sticky.</p>
        <p>Returns <c>ok</c> if successful or <c>error</c> if not.</p>
      </desc>
    </func>
    <func>
      <name name="is_sticky" arity="1"/>
      <fsummary>Test whether a module is sticky</fsummary>
      <desc>
        <p>This function returns <c>true</c> if <c><anno>Module</anno></c> is the
	name of a module that has been loaded from a sticky directory
	(or in other words: an attempt to reload the module will fail),
	or <c>false</c> if <c><anno>Module</anno></c> is not a loaded module or is
	not sticky.</p>
      </desc>
    </func>
    <func>
      <name name="where_is_file" arity="1"/>
      <fsummary>Full name of a file located in the code path</fsummary>
      <desc>
        <p>Searches the code path for <c><anno>Filename</anno></c>, a file of
          arbitrary type. If found, the full name is returned.
          <c>non_existing</c> is returned if the file cannot be found.
          The function can be useful, for example, to locate
          application resource files.</p>
      </desc>
    </func>
    <func>
      <name name="clash" arity="0"/>
      <fsummary>Search for modules with identical names.</fsummary>
      <desc>
        <p>Searches the entire code space for module names with
          identical names and writes a report to <c>stdout</c>.</p>
      </desc>
    </func>
    <func>
      <name name="is_module_native" arity="1"/>
      <fsummary>Test whether a module has native code</fsummary>
      <desc>
        <p>This function returns <c>true</c> if <c><anno>Module</anno></c> is
	name of a loaded module that has native code loaded, and 
	<c>false</c> if <c><anno>Module</anno></c> is loaded but does not have
	native. If <c><anno>Module</anno></c> is not loaded, this function returns
	<c>undefined</c>.</p>
      </desc>
    </func>

    <func>
      <name name="get_mode" arity="0"/>
      <fsummary>The code_server's mode.</fsummary>
      <desc>
        <p>This function returns an atom describing the code_server's mode:
        <c>interactive</c> or <c>embedded</c>. </p>
        <p>This information is useful when an external entity (for example,
        an IDE) provides additional code for a running node. If in interactive
        mode, it only needs to add to the code path. If in embedded mode,
        the code has to be loaded with <c>load_binary/3</c></p>
      </desc>
    </func>
  </funcs>
</erlref>