1code(3) Erlang Module Definition code(3)
2
6 code - Erlang code server.
7
9 This module contains the interface to the Erlang code server, which
10 deals with the loading of compiled code into a running Erlang runtime
11 system.
12 The runtime system can be started in interactive or embedded mode.
14 Which one is decided by the command-line flag -mode:
15 % erl -mode interactive
17 The modes are as follows:
19 * In interactive mode, which is default, only some code is loaded
21 during system startup, basically the modules needed by the runtime
22 system. Other code is dynamically loaded when first referenced.
23 When a call to a function in a certain module is made, and the mod‐
24 ule is not loaded, the code server searches for and tries to load
25 the module.
26 * In embedded mode, modules are not auto loaded. Trying to use a mod‐
28 ule that has not been loaded results in an error. This mode is rec‐
29 ommended when the boot script loads all modules, as it is typically
30 done in OTP releases. (Code can still be loaded later by explicitly
31 ordering the code server to do so).
32 To prevent accidentally reloading of modules affecting the Erlang run‐
34 time system, directories kernel, stdlib, and compiler are considered
35 sticky. This means that the system issues a warning and rejects the re‐
36 quest if a user tries to reload a module residing in any of them. The
37 feature can be disabled by using command-line flag -nostick.
38
40 In interactive mode, the code server maintains a search path, usually
41 called the code path, consisting of a list of directories, which it
42 searches sequentially when trying to load a module.
43 Initially, the code path consists of the current working directory and
45 all Erlang object code directories under library directory $OTP‐
46 ROOT/lib, where $OTPROOT is the installation directory of Erlang/OTP,
47 code:root_dir(). Directories can be named Name[-Vsn] and the code
48 server, by default, chooses the directory with the highest version num‐
49 ber among those having the same Name. Suffix -Vsn is optional. If an
50 ebin directory exists under Name[-Vsn], this directory is added to the
51 code path.
52 Environment variable ERL_LIBS (defined in the operating system) can be
54 used to define more library directories to be handled in the same way
55 as the standard OTP library directory described above, except that di‐
56 rectories without an ebin directory are ignored.
57 All application directories found in the additional directories appear
59 before the standard OTP applications, except for the Kernel and STDLIB
60 applications, which are placed before any additional applications. In
61 other words, modules found in any of the additional library directories
62 override modules with the same name in OTP, except for modules in Ker‐
63 nel and STDLIB.
64 Environment variable ERL_LIBS (if defined) is to contain a colon-sepa‐
66 rated (for Unix-like systems) or semicolon-separated (for Windows) list
67 of additional libraries.
68 Example:
70 On a Unix-like system, ERL_LIBS can be set to the following
72 /usr/local/jungerl:/home/some_user/my_erlang_lib
74 On Windows, use semi-colon as separator.
76
78 Warning:
79 The support for loading code from archive files is experimental. The
80 purpose of releasing it before it is ready is to obtain early feedback.
81 The file format, semantics, interfaces, and so on, can be changed in a
82 future release. The function lib_dir/2 and flag -code_path_choice are
83 also experimental.
84 The Erlang archives are ZIP files with extension .ez. Erlang archives
87 can also be enclosed in escript files whose file extension is arbi‐
88 trary.
89 Erlang archive files can contain entire Erlang applications or parts of
91 applications. The structure in an archive file is the same as the di‐
92 rectory structure for an application. If you, for example, create an
93 archive of mnesia-4.4.7, the archive file must be named mnesia-4.4.7.ez
94 and it must contain a top directory named mnesia-4.4.7. If the version
95 part of the name is omitted, it must also be omitted in the archive.
96 That is, a mnesia.ez archive must contain a mnesia top directory.
97 An archive file for an application can, for example, be created like
99 this:
100 zip:create("mnesia-4.4.7.ez",
102 ["mnesia-4.4.7"],
103 [{cwd, code:lib_dir()},
104 {compress, all},
105 {uncompress,[".beam",".app"]}]).
106 Any file in the archive can be compressed, but to speed up the access
108 of frequently read files, it can be a good idea to store beam and app
109 files uncompressed in the archive.
110 Normally the top directory of an application is located in library di‐
112 rectory $OTPROOT/lib or in a directory referred to by environment vari‐
113 able ERL_LIBS. At startup, when the initial code path is computed, the
114 code server also looks for archive files in these directories and pos‐
115 sibly adds ebin directories in archives to the code path. The code path
116 then contains paths to directories that look like $OTPROOT/lib/mne‐
117 sia.ez/mnesia/ebin or $OTPROOT/lib/mnesia-4.4.7.ez/mnesia-4.4.7/ebin.
118 The code server uses module erl_prim_loader in ERTS (possibly through
120 erl_boot_server) to read code files from archives. However, the func‐
121 tions in erl_prim_loader can also be used by other applications to read
122 files from archives. For example, the call erl_prim_loader:list_dir(
123 "/otp/root/lib/mnesia-4.4.7.ez/mnesia-4.4.7/examples/bench)" would list
124 the contents of a directory inside an archive. See erl_prim_loader(3).
125 An application archive file and a regular application directory can co‐
127 exist. This can be useful when it is needed to have parts of the appli‐
128 cation as regular files. A typical case is the priv directory, which
129 must reside as a regular directory to link in drivers dynamically and
130 start port programs. For other applications that do not need this, di‐
131 rectory priv can reside in the archive and the files under the direc‐
132 tory priv can be read through erl_prim_loader.
133 When a directory is added to the code path and when the entire code
135 path is (re)set, the code server decides which subdirectories in an ap‐
136 plication that are to be read from the archive and which that are to be
137 read as regular files. If directories are added or removed afterwards,
138 the file access can fail if the code path is not updated (possibly to
139 the same path as before, to trigger the directory resolution update).
140 For each directory on the second level in the application archive
142 (ebin, priv, src, and so on), the code server first chooses the regular
143 directory if it exists and second from the archive. Function
144 code:lib_dir/2 returns the path to the subdirectory. For example,
145 code:lib_dir(megaco,ebin) can return
146 /otp/root/lib/megaco-3.9.1.1.ez/megaco-3.9.1.1/ebin while
147 code:lib_dir(megaco,priv) can return /otp/root/lib/megaco-3.9.1.1/priv.
148 When an escript file contains an archive, there are no restrictions on
150 the name of the escript and no restrictions on how many applications
151 that can be stored in the embedded archive. Single Beam files can also
152 reside on the top level in the archive. At startup, the top directory
153 in the embedded archive and all (second level) ebin directories in the
154 embedded archive are added to the code path. See erts:escript(1).
155 When the choice of directories in the code path is strict, the direc‐
157 tory that ends up in the code path is exactly the stated one. This
158 means that if, for example, the directory $OTPROOT/lib/mne‐
159 sia-4.4.7/ebin is explicitly added to the code path, the code server
160 does not load files from $OTPROOT/lib/mnesia-4.4.7.ez/mne‐
161 sia-4.4.7/ebin.
162 This behavior can be controlled through command-line flag
164 -code_path_choice Choice. If the flag is set to relaxed, the code
165 server instead chooses a suitable directory depending on the actual
166 file structure. If a regular application ebin directory exists, it is
167 chosen. Otherwise, the directory ebin in the archive is chosen if it
168 exists. If neither of them exists, the original directory is chosen.
169 Command-line flag -code_path_choice Choice also affects how module init
171 interprets the boot script. The interpretation of the explicit code
172 paths in the boot script can be strict or relaxed. It is particularly
173 useful to set the flag to relaxed when elaborating with code loading
174 from archives without editing the boot script. The default is relaxed.
175 See erts:init(3).
176
178 The code for a module can exist in two variants in a system: current
179 code and old code. When a module is loaded into the system for the
180 first time, the module code becomes 'current' and the global export ta‐
181 ble is updated with references to all functions exported from the mod‐
182 ule.
183 If then a new instance of the module is loaded (for example, because of
185 error correction), the code of the previous instance becomes 'old', and
186 all export entries referring to the previous instance are removed. Af‐
187 ter that, the new instance is loaded as for the first time, and becomes
188 'current'.
189 Both old and current code for a module are valid, and can even be eval‐
191 uated concurrently. The difference is that exported functions in old
192 code are unavailable. Hence, a global call cannot be made to an ex‐
193 ported function in old code, but old code can still be evaluated be‐
194 cause of processes lingering in it.
195 If a third instance of the module is loaded, the code server removes
197 (purges) the old code and any processes lingering in it are terminated.
198 Then the third instance becomes 'current' and the previously current
199 code becomes 'old'.
200 For more information about old and current code, and how to make a
202 process switch from old to current code, see section Compilation and
203 Code Loading in the Erlang Reference Manual.
204
206 Module and application names are atoms, while file and directory names
207 are strings. For backward compatibility reasons, some functions accept
208 both strings and atoms, but a future release will probably only allow
209 the arguments that are documented.
210 Functions in this module generally fail with an exception if they are
212 passed an incorrect type (for example, an integer or a tuple where an
213 atom is expected). An error tuple is returned if the argument type is
214 correct, but there are some other errors (for example, a non-existing
215 directory is specified to set_path/1).
216
218 Functions that load code (such as load_file/1) will return {error,Rea‐
219 son} if the load operation fails. Here follows a description of the
220 common reasons.
221 badfile:
223 The object code has an incorrect format or the module name in the
224 object code is not the expected module name.
225 nofile:
227 No file with object code was found.
228 not_purged:
230 The object code could not be loaded because an old version of the
231 code already existed.
232 on_load_failure:
234 The module has an -on_load function that failed when it was called.
235 sticky_directory:
237 The object code resides in a sticky directory.
238
240 load_ret() =
241 {error, What :: load_error_rsn()} |
242 {module, Module :: module()}
243 load_error_rsn() =
245 badfile | nofile | not_purged | on_load_failure |
246 sticky_directory
247 module_status() = not_loaded | loaded | modified | removed
249 prepared_code()
251 An opaque term holding prepared code.
253
255 set_path(Path) -> true | {error, What}
256 Types:
258 Path = [Dir :: file:filename()]
260 What = bad_directory
261 Sets the code path to the list of directories Path.
263 Returns:
265 true:
267 If successful
268 {error, bad_directory}:
270 If any Dir is not a directory name
271 get_path() -> Path
273 Types:
275 Path = [Dir :: file:filename()]
277 Returns the code path.
279 add_path(Dir) -> add_path_ret()
281 add_pathz(Dir) -> add_path_ret()
283 Types:
285 Dir = file:filename()
287 add_path_ret() = true | {error, bad_directory}
288 Adds Dir to the code path. The directory is added as the last
290 directory in the new path. If Dir already exists in the path, it
291 is not added.
292 Returns true if successful, or {error, bad_directory} if Dir is
294 not the name of a directory.
295 add_patha(Dir) -> add_path_ret()
297 Types:
299 Dir = file:filename()
301 add_path_ret() = true | {error, bad_directory}
302 Adds Dir to the beginning of the code path. If Dir exists, it is
304 removed from the old position in the code path.
305 Returns true if successful, or {error, bad_directory} if Dir is
307 not the name of a directory.
308 add_paths(Dirs) -> ok
310 add_pathsz(Dirs) -> ok
312 Types:
314 Dirs = [Dir :: file:filename()]
316 Adds the directories in Dirs to the end of the code path. If a
318 Dir exists, it is not added.
319 Always returns ok, regardless of the validity of each individual
321 Dir.
322 add_pathsa(Dirs) -> ok
324 Types:
326 Dirs = [Dir :: file:filename()]
328 Traverses Dirs and adds each Dir to the beginning of the code
330 path. This means that the order of Dirs is reversed in the re‐
331 sulting code path. For example, if you add [Dir1,Dir2], the re‐
332 sulting path will be [Dir2,Dir1|OldCodePath].
333 If a Dir already exists in the code path, it is removed from the
335 old position.
336 Always returns ok, regardless of the validity of each individual
338 Dir.
339 del_path(NameOrDir) -> boolean() | {error, What}
341 Types:
343 NameOrDir = Name | Dir
345 Name = atom()
346 Dir = file:filename()
347 What = bad_name
348 Deletes a directory from the code path. The argument can be an
350 atom Name, in which case the directory with the name
351 .../Name[-Vsn][/ebin] is deleted from the code path. Also, the
352 complete directory name Dir can be specified as argument.
353 Returns:
355 true:
357 If successful
358 false:
360 If the directory is not found
361 {error, bad_name}:
363 If the argument is invalid
364 replace_path(Name, Dir) -> true | {error, What}
366 Types:
368 Name = atom()
370 Dir = file:filename()
371 What = bad_directory | bad_name | {badarg, term()}
372 Replaces an old occurrence of a directory named
374 .../Name[-Vsn][/ebin] in the code path, with Dir. If Name does
375 not exist, it adds the new directory Dir last in the code path.
376 The new directory must also be named .../Name[-Vsn][/ebin]. This
377 function is to be used if a new version of the directory (li‐
378 brary) is added to a running system.
379 Returns:
381 true:
383 If successful
384 {error, bad_name}:
386 If Name is not found
387 {error, bad_directory}:
389 If Dir does not exist
390 {error, {badarg, [Name, Dir]}}:
392 If Name or Dir is invalid
393 load_file(Module) -> load_ret()
395 Types:
397 Module = module()
399 load_ret() =
400 {error, What :: load_error_rsn()} |
401 {module, Module :: module()}
402 Tries to load the Erlang module Module, using the code path. It
404 looks for the object code file with an extension corresponding
405 to the Erlang machine used, for example, Module.beam. The load‐
406 ing fails if the module name found in the object code differs
407 from the name Module. load_binary/3 must be used to load object
408 code with a module name that is different from the file name.
409 Returns {module, Module} if successful, or {error, Reason} if
411 loading fails. See Error Reasons for Code-Loading Functions for
412 a description of the possible error reasons.
413 load_abs(Filename) -> load_ret()
415 Types:
417 Filename = file:filename()
419 load_ret() =
420 {error, What :: load_error_rsn()} |
421 {module, Module :: module()}
422 loaded_filename() =
423 (Filename :: file:filename()) | loaded_ret_atoms()
424 loaded_ret_atoms() = cover_compiled | preloaded
425 Same as load_file(Module), but Filename is an absolute or rela‐
427 tive filename. The code path is not searched. It returns a value
428 in the same way as load_file/1. Notice that Filename must not
429 contain the extension (for example, .beam) because load_abs/1
430 adds the correct extension.
431 ensure_loaded(Module) -> {module, Module} | {error, What}
433 Types:
435 Module = module()
437 What = embedded | badfile | nofile | on_load_failure
438 Tries to load a module in the same way as load_file/1, unless
440 the module is already loaded. However, in embedded mode it does
441 not load a module that is not already loaded, but returns {er‐
442 ror, embedded} instead. See Error Reasons for Code-Loading Func‐
443 tions for a description of other possible error reasons.
444 load_binary(Module, Filename, Binary) ->
446 {module, Module} | {error, What}
447 Types:
449 Module = module()
451 Filename = loaded_filename()
452 Binary = binary()
453 What = badarg | load_error_rsn()
454 loaded_filename() =
455 (Filename :: file:filename()) | loaded_ret_atoms()
456 loaded_ret_atoms() = cover_compiled | preloaded
457 This function can be used to load object code on remote Erlang
459 nodes. Argument Binary must contain object code for Module.
460 Filename is only used by the code server to keep a record of
461 from which file the object code for Module comes. Thus, Filename
462 is not opened and read by the code server.
463 Returns {module, Module} if successful, or {error, Reason} if
465 loading fails. See Error Reasons for Code-Loading Functions for
466 a description of the possible error reasons.
467 atomic_load(Modules) -> ok | {error, [{Module, What}]}
469 Types:
471 Modules = [Module | {Module, Filename, Binary}]
473 Module = module()
474 Filename = file:filename()
475 Binary = binary()
476 What =
477 badfile | nofile | on_load_not_allowed | duplicated |
478 not_purged | sticky_directory | pending_on_load
479 Tries to load all of the modules in the list Modules atomically.
481 That means that either all modules are loaded at the same time,
482 or none of the modules are loaded if there is a problem with any
483 of the modules.
484 Loading can fail for one the following reasons:
486 badfile:
488 The object code has an incorrect format or the module name
489 in the object code is not the expected module name.
490 nofile:
492 No file with object code exists.
493 on_load_not_allowed:
495 A module contains an -on_load function.
496 duplicated:
498 A module is included more than once in Modules.
499 not_purged:
501 The object code cannot be loaded because an old version of
502 the code already exists.
503 sticky_directory:
505 The object code resides in a sticky directory.
506 pending_on_load:
508 A previously loaded module contains an -on_load function
509 that never finished.
510 If it is important to minimize the time that an application is
512 inactive while changing code, use prepare_loading/1 and fin‐
513 ish_loading/1 instead of atomic_load/1. Here is an example:
514 {ok,Prepared} = code:prepare_loading(Modules),
516 %% Put the application into an inactive state or do any
517 %% other preparation needed before changing the code.
518 ok = code:finish_loading(Prepared),
519 %% Resume the application.
520 prepare_loading(Modules) ->
522 {ok, Prepared} | {error, [{Module, What}]}
523 Types:
525 Modules = [Module | {Module, Filename, Binary}]
527 Module = module()
528 Filename = file:filename()
529 Binary = binary()
530 Prepared = prepared_code()
531 What = badfile | nofile | on_load_not_allowed | duplicated
532 Prepares to load the modules in the list Modules. Finish the
534 loading by calling finish_loading(Prepared).
535 This function can fail with one of the following error reasons:
537 badfile:
539 The object code has an incorrect format or the module name
540 in the object code is not the expected module name.
541 nofile:
543 No file with object code exists.
544 on_load_not_allowed:
546 A module contains an -on_load function.
547 duplicated:
549 A module is included more than once in Modules.
550 finish_loading(Prepared) -> ok | {error, [{Module, What}]}
552 Types:
554 Prepared = prepared_code()
556 Module = module()
557 What = not_purged | sticky_directory | pending_on_load
558 Tries to load code for all modules that have been previously
560 prepared by prepare_loading/1. The loading occurs atomically,
561 meaning that either all modules are loaded at the same time, or
562 none of the modules are loaded.
563 This function can fail with one of the following error reasons:
565 not_purged:
567 The object code cannot be loaded because an old version of
568 the code already exists.
569 sticky_directory:
571 The object code resides in a sticky directory.
572 pending_on_load:
574 A previously loaded module contains an -on_load function
575 that never finished.
576 ensure_modules_loaded(Modules :: [Module]) ->
578 ok | {error, [{Module, What}]}
579 Types:
581 Module = module()
583 What = badfile | nofile | on_load_failure
584 Tries to load any modules not already loaded in the list Modules
586 in the same way as load_file/1.
587 Returns ok if successful, or {error,[{Module,Reason}]} if load‐
589 ing of some modules fails. See Error Reasons for Code-Loading
590 Functions for a description of other possible error reasons.
591 delete(Module) -> boolean()
593 Types:
595 Module = module()
597 Removes the current code for Module, that is, the current code
599 for Module is made old. This means that processes can continue
600 to execute the code in the module, but no external function
601 calls can be made to it.
602 Returns true if successful, or false if there is old code for
604 Module that must be purged first, or if Module is not a (loaded)
605 module.
606 purge(Module) -> boolean()
608 Types:
610 Module = module()
612 Purges the code for Module, that is, removes code marked as old.
614 If some processes still linger in the old code, these processes
615 are killed before the code is removed.
616 Note:
618 As of ERTS version 9.0, a process is only considered to be lin‐
619 gering in the code if it has direct references to the code. For
620 more information see documentation of er‐
621 lang:check_process_code/3, which is used in order to determine
622 this.
623 Returns true if successful and any process is needed to be
626 killed, otherwise false.
627 soft_purge(Module) -> boolean()
629 Types:
631 Module = module()
633 Purges the code for Module, that is, removes code marked as old,
635 but only if no processes linger in it.
636 Note:
638 As of ERTS version 9.0, a process is only considered to be lin‐
639 gering in the code if it has direct references to the code. For
640 more information see documentation of er‐
641 lang:check_process_code/3, which is used in order to determine
642 this.
643 Returns false if the module cannot be purged because of pro‐
646 cesses lingering in old code, otherwise true.
647 is_loaded(Module) -> {file, Loaded} | false
649 Types:
651 Module = module()
653 Loaded = loaded_filename()
654 loaded_filename() =
655 (Filename :: file:filename()) | loaded_ret_atoms()
656 Filename is an absolute filename.
657 loaded_ret_atoms() = cover_compiled | preloaded
658 Checks if Module is loaded. If it is, {file, Loaded} is re‐
660 turned, otherwise false.
661 Normally, Loaded is the absolute filename Filename from which
663 the code is obtained. If the module is preloaded (see
664 script(4)), Loaded==preloaded. If the module is Cover-compiled
665 (see cover(3)), Loaded==cover_compiled.
666 all_available() -> [{Module, Filename, Loaded}]
668 Types:
670 Module = string()
672 Filename = loaded_filename()
673 Loaded = boolean()
674 loaded_filename() =
675 (Filename :: file:filename()) | loaded_ret_atoms()
676 Filename is an absolute filename.
677 loaded_ret_atoms() = cover_compiled | preloaded
678 Returns a list of tuples {Module, Filename, Loaded} for all
680 available modules. A module is considered to be available if it
681 either is loaded or would be loaded if called. Filename is nor‐
682 mally the absolute filename, as described for is_loaded/1.
683 all_loaded() -> [{Module, Loaded}]
685 Types:
687 Module = module()
689 Loaded = loaded_filename()
690 loaded_filename() =
691 (Filename :: file:filename()) | loaded_ret_atoms()
692 Filename is an absolute filename.
693 loaded_ret_atoms() = cover_compiled | preloaded
694 Returns a list of tuples {Module, Loaded} for all loaded mod‐
696 ules. Loaded is normally the absolute filename, as described for
697 is_loaded/1.
698 which(Module) -> Which
700 Types:
702 Module = module()
704 Which = loaded_filename() | non_existing
705 loaded_filename() =
706 (Filename :: file:filename()) | loaded_ret_atoms()
707 loaded_ret_atoms() = cover_compiled | preloaded
708 If the module is not loaded, this function searches the code
710 path for the first file containing object code for Module and
711 returns the absolute filename.
712 If the module is loaded, it returns the name of the file con‐
714 taining the loaded object code.
715 If the module is preloaded, preloaded is returned.
717 If the module is Cover-compiled, cover_compiled is returned.
719 If the module cannot be found, non_existing is returned.
721 get_object_code(Module) -> {Module, Binary, Filename} | error
723 Types:
725 Module = module()
727 Binary = binary()
728 Filename = file:filename()
729 Searches the code path for the object code of module Module. Re‐
731 turns {Module, Binary, Filename} if successful, otherwise error.
732 Binary is a binary data object, which contains the object code
733 for the module. This can be useful if code is to be loaded on a
734 remote node in a distributed system. For example, loading module
735 Module on a node Node is done as follows:
736 {_Module, Binary, Filename} = code:get_object_code(Module),
738 rpc:call(Node, code, load_binary, [Module, Filename, Binary]),
739 get_doc(Mod) -> {ok, Res} | {error, Reason}
741 Types:
743 Mod = module()
745 Res = #docs_v1{}
746 Reason = non_existing | missing | file:posix()
747 Searches the code path for EEP-48 style documentation and re‐
749 turns it if available. If no documentation can be found the
750 function tries to generate documentation from the debug informa‐
751 tion in the module. If no debug information is available, this
752 function will return {error,missing}.
753 For more information about the documentation chunk see Documen‐
755 tation Storage and Format in Kernel's User's Guide.
756 root_dir() -> file:filename()
758 Returns the root directory of Erlang/OTP, which is the directory
760 where it is installed.
761 Example:
763 > code:root_dir().
765 "/usr/local/otp"
766 lib_dir() -> file:filename()
768 Returns the library directory, $OTPROOT/lib, where $OTPROOT is
770 the root directory of Erlang/OTP.
771 Example:
773 > code:lib_dir().
775 "/usr/local/otp/lib"
776 lib_dir(Name) -> file:filename() | {error, bad_name}
778 Types:
780 Name = atom()
782 Returns the path for the "library directory", the top directory,
784 for an application Name located under $OTPROOT/lib or on a di‐
785 rectory referred to with environment variable ERL_LIBS.
786 If a regular directory called Name or Name-Vsn exists in the
788 code path with an ebin subdirectory, the path to this directory
789 is returned (not the ebin directory).
790 If the directory refers to a directory in an archive, the ar‐
792 chive name is stripped away before the path is returned. For ex‐
793 ample, if directory /usr/local/otp/lib/mnesia-4.2.2.ez/mne‐
794 sia-4.2.2/ebin is in the path, /usr/local/otp/lib/mne‐
795 sia-4.2.2/ebin is returned. This means that the library direc‐
796 tory for an application is the same, regardless if the applica‐
797 tion resides in an archive or not.
798 Example:
800 > code:lib_dir(mnesia).
802 "/usr/local/otp/lib/mnesia-4.2.2"
803 Returns {error, bad_name} if Name is not the name of an applica‐
805 tion under $OTPROOT/lib or on a directory referred to through
806 environment variable ERL_LIBS. Fails with an exception if Name
807 has the wrong type.
808 Warning:
810 For backward compatibility, Name is also allowed to be a string.
811 That will probably change in a future release.
812 lib_dir(Name, SubDir) -> file:filename() | {error, bad_name}
815 Types:
817 Name = SubDir = atom()
819 Returns the path to a subdirectory directly under the top direc‐
821 tory of an application. Normally the subdirectories reside under
822 the top directory for the application, but when applications at
823 least partly reside in an archive, the situation is different.
824 Some of the subdirectories can reside as regular directories
825 while others reside in an archive file. It is not checked
826 whether this directory exists.
827 Example:
829 > code:lib_dir(megaco, priv).
831 "/usr/local/otp/lib/megaco-3.9.1.1/priv"
832 Fails with an exception if Name or SubDir has the wrong type.
834 compiler_dir() -> file:filename()
836 Returns the compiler library directory. Equivalent to
838 code:lib_dir(compiler).
839 priv_dir(Name) -> file:filename() | {error, bad_name}
841 Types:
843 Name = atom()
845 Returns the path to the priv directory in an application. Equiv‐
847 alent to code:lib_dir(Name, priv).
848 Warning:
850 For backward compatibility, Name is also allowed to be a string.
851 That will probably change in a future release.
852 objfile_extension() -> nonempty_string()
855 Returns the object code file extension corresponding to the Er‐
857 lang machine used, namely .beam.
858 stick_dir(Dir) -> ok | error
860 Types:
862 Dir = file:filename()
864 Marks Dir as sticky.
866 Returns ok if successful, otherwise error.
868 unstick_dir(Dir) -> ok | error
870 Types:
872 Dir = file:filename()
874 Unsticks a directory that is marked as sticky.
876 Returns ok if successful, otherwise error.
878 is_sticky(Module) -> boolean()
880 Types:
882 Module = module()
884 Returns true if Module is the name of a module that has been
886 loaded from a sticky directory (in other words: an attempt to
887 reload the module will fail), or false if Module is not a loaded
888 module or is not sticky.
889 where_is_file(Filename) -> non_existing | Absname
891 Types:
893 Filename = Absname = file:filename()
895 Searches the code path for Filename, a file of arbitrary type.
897 If found, the full name is returned. non_existing is returned if
898 the file cannot be found. The function can be useful, for exam‐
899 ple, to locate application resource files.
900 clash() -> ok
902 Searches all directories in the code path for module names with
904 identical names and writes a report to stdout.
905 module_status() -> [{module(), module_status()}]
907 Types:
909 module_status() = not_loaded | loaded | modified | removed
911 See module_status/1 and all_loaded/0 for details.
913 module_status(Module :: module() | [module()]) ->
915 module_status() | [{module(), module_status()}]
916 Types:
918 module_status() = not_loaded | loaded | modified | removed
920 The status of a module can be one of:
922 not_loaded:
924 If Module is not currently loaded.
925 loaded:
927 If Module is loaded and the object file exists and contains
928 the same code.
929 removed:
931 If Module is loaded but no corresponding object file can be
932 found in the code path.
933 modified:
935 If Module is loaded but the object file contains code with a
936 different MD5 checksum.
937 Preloaded modules are always reported as loaded, without in‐
939 specting the contents on disk. Cover compiled modules will al‐
940 ways be reported as modified if an object file exists, or as re‐
941 moved otherwise. Modules whose load path is an empty string
942 (which is the convention for auto-generated code) will only be
943 reported as loaded or not_loaded.
944 See also modified_modules/0.
946 modified_modules() -> [module()]
948 Returns the list of all currently loaded modules for which mod‐
950 ule_status/1 returns modified. See also all_loaded/0.
951 is_module_native(Module) -> true | false | undefined
953 Types:
955 Module = module()
957 Returns false if the given Module is loaded, and undefined if it
959 is not.
960 Warning:
962 This function is deprecated and will be removed in a future re‐
963 lease.
964 get_mode() -> embedded | interactive
967 Returns an atom describing the mode of the code server: interac‐
969 tive or embedded.
970 This information is useful when an external entity (for example,
972 an IDE) provides additional code for a running node. If the code
973 server is in interactive mode, it only has to add the path to
974 the code. If the code server is in embedded mode, the code must
975 be loaded with load_binary/3.
976Ericsson AB kernel 8.5.4.2 code(3)