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 embedded or interactive mode.
14 Which one is decided by command-line flag -mode:
15 % erl -mode interactive
17 The modes are as follows:
19 * In embedded mode, all code is loaded during system startup accord‐
21 ing to the boot script. (Code can also be loaded later by explic‐
22 itly ordering the code server to do so).
23 * In interactive mode, which is default, only some code is loaded
25 during system startup, basically the modules needed by the runtime
26 system. Other code is dynamically loaded when first referenced.
27 When a call to a function in a certain module is made, and the mod‐
28 ule is not loaded, the code server searches for and tries to load
29 the module.
30 To prevent accidentally reloading of modules affecting the Erlang run‐
32 time system, directories kernel, stdlib, and compiler are considered
33 sticky. This means that the system issues a warning and rejects the
34 request if a user tries to reload a module residing in any of them. The
35 feature can be disabled by using command-line flag -nostick.
36
38 In interactive mode, the code server maintains a search path, usually
39 called the code path, consisting of a list of directories, which it
40 searches sequentially when trying to load a module.
41 Initially, the code path consists of the current working directory and
43 all Erlang object code directories under library directory $OTP‐
44 ROOT/lib, where $OTPROOT is the installation directory of Erlang/OTP,
45 code:root_dir(). Directories can be named Name[-Vsn] and the code
46 server, by default, chooses the directory with the highest version num‐
47 ber among those having the same Name. Suffix -Vsn is optional. If an
48 ebin directory exists under Name[-Vsn], this directory is added to the
49 code path.
50 Environment variable ERL_LIBS (defined in the operating system) can be
52 used to define more library directories to be handled in the same way
53 as the standard OTP library directory described above, except that
54 directories without an ebin directory are ignored.
55 All application directories found in the additional directories appears
57 before the standard OTP applications, except for the Kernel and STDLIB
58 applications, which are placed before any additional applications. In
59 other words, modules found in any of the additional library directories
60 override modules with the same name in OTP, except for modules in Ker‐
61 nel and STDLIB.
62 Environment variable ERL_LIBS (if defined) is to contain a colon-sepa‐
64 rated (for Unix-like systems) or semicolon-separated (for Windows) list
65 of additional libraries.
66 Example:
68 On a Unix-like system, ERL_LIBS can be set to the following
70 /usr/local/jungerl:/home/some_user/my_erlang_lib
72 On Windows, use semi-colon as separator.
74
76 Warning:
77 The support for loading code from archive files is experimental. The
78 purpose of releasing it before it is ready is to obtain early feedback.
79 The file format, semantics, interfaces, and so on, can be changed in a
80 future release. The function lib_dir/2 and flag -code_path_choice are
81 also experimental.
82 The Erlang archives are ZIP files with extension .ez. Erlang archives
85 can also be enclosed in escript files whose file extension is arbi‐
86 trary.
87 Erlang archive files can contain entire Erlang applications or parts of
89 applications. The structure in an archive file is the same as the
90 directory structure for an application. If you, for example, create an
91 archive of mnesia-4.4.7, the archive file must be named mnesia-4.4.7.ez
92 and it must contain a top directory named mnesia-4.4.7. If the version
93 part of the name is omitted, it must also be omitted in the archive.
94 That is, a mnesia.ez archive must contain a mnesia top directory.
95 An archive file for an application can, for example, be created like
97 this:
98 zip:create("mnesia-4.4.7.ez",
100 ["mnesia-4.4.7"],
101 [{cwd, code:lib_dir()},
102 {compress, all},
103 {uncompress,[".beam",".app"]}]).
104 Any file in the archive can be compressed, but to speed up the access
106 of frequently read files, it can be a good idea to store beam and app
107 files uncompressed in the archive.
108 Normally the top directory of an application is located in library
110 directory $OTPROOT/lib or in a directory referred to by environment
111 variable ERL_LIBS. At startup, when the initial code path is computed,
112 the code server also looks for archive files in these directories and
113 possibly adds ebin directories in archives to the code path. The code
114 path then contains paths to directories that look like $OTP‐
115 ROOT/lib/mnesia.ez/mnesia/ebin or $OTPROOT/lib/mnesia-4.4.7.ez/mne‐
116 sia-4.4.7/ebin.
117 The code server uses module erl_prim_loader in ERTS (possibly through
119 erl_boot_server) to read code files from archives. However, the func‐
120 tions in erl_prim_loader can also be used by other applications to read
121 files from archives. For example, the call erl_prim_loader:list_dir(
122 "/otp/root/lib/mnesia-4.4.7.ez/mnesia-4.4.7/examples/bench)" would list
123 the contents of a directory inside an archive. See erl_prim_loader(3).
124 An application archive file and a regular application directory can
126 coexist. This can be useful when it is needed to have parts of the
127 application as regular files. A typical case is the priv directory,
128 which must reside as a regular directory to link in drivers dynamically
129 and start port programs. For other applications that do not need this,
130 directory priv can reside in the archive and the files under the direc‐
131 tory priv can be read through erl_prim_loader.
132 When a directory is added to the code path and when the entire code
134 path is (re)set, the code server decides which subdirectories in an
135 application that are to be read from the archive and which that are to
136 be read as regular files. If directories are added or removed after‐
137 wards, the file access can fail if the code path is not updated (possi‐
138 bly to the same path as before, to trigger the directory resolution
139 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.
187 After that, the new instance is loaded as for the first time, and
188 becomes '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
193 exported function in old code, but old code can still be evaluated
194 because 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 |
246 nofile |
247 not_purged |
248 on_load_failure |
249 sticky_directory
250 prepared_code()
252 An opaque term holding prepared code.
254
256 set_path(Path) -> true | {error, What}
257 Types:
259 Path = [Dir :: file:filename()]
261 What = bad_directory
262 Sets the code path to the list of directories Path.
264 Returns:
266 true:
268 If successful
269 {error, bad_directory}:
271 If any Dir is not a directory name
272 get_path() -> Path
274 Types:
276 Path = [Dir :: file:filename()]
278 Returns the code path.
280 add_path(Dir) -> add_path_ret()
282 add_pathz(Dir) -> add_path_ret()
284 Types:
286 Dir = file:filename()
288 add_path_ret() = true | {error, bad_directory}
289 Adds Dir to the code path. The directory is added as the last
291 directory in the new path. If Dir already exists in the path, it
292 is not added.
293 Returns true if successful, or {error, bad_directory} if Dir is
295 not the name of a directory.
296 add_patha(Dir) -> add_path_ret()
298 Types:
300 Dir = file:filename()
302 add_path_ret() = true | {error, bad_directory}
303 Adds Dir to the beginning of the code path. If Dir exists, it is
305 removed from the old position in the code path.
306 Returns true if successful, or {error, bad_directory} if Dir is
308 not the name of a directory.
309 add_paths(Dirs) -> ok
311 add_pathsz(Dirs) -> ok
313 Types:
315 Dirs = [Dir :: file:filename()]
317 Adds the directories in Dirs to the end of the code path. If a
319 Dir exists, it is not added.
320 Always returns ok, regardless of the validity of each individual
322 Dir.
323 add_pathsa(Dirs) -> ok
325 Types:
327 Dirs = [Dir :: file:filename()]
329 Traverses Dirs and adds each Dir to the beginning of the code
331 path. This means that the order of Dirs is reversed in the
332 resulting code path. For example, if you add [Dir1,Dir2], the
333 resulting path will be [Dir2,Dir1|OldCodePath].
334 If a Dir already exists in the code path, it is removed from the
336 old position.
337 Always returns ok, regardless of the validity of each individual
339 Dir.
340 del_path(NameOrDir) -> boolean() | {error, What}
342 Types:
344 NameOrDir = Name | Dir
346 Name = atom()
347 Dir = file:filename()
348 What = bad_name
349 Deletes a directory from the code path. The argument can be an
351 atom Name, in which case the directory with the name
352 .../Name[-Vsn][/ebin] is deleted from the code path. Also, the
353 complete directory name Dir can be specified as argument.
354 Returns:
356 true:
358 If successful
359 false:
361 If the directory is not found
362 {error, bad_name}:
364 If the argument is invalid
365 replace_path(Name, Dir) -> true | {error, What}
367 Types:
369 Name = atom()
371 Dir = file:filename()
372 What = bad_directory | bad_name | {badarg, term()}
373 Replaces an old occurrence of a directory named
375 .../Name[-Vsn][/ebin] in the code path, with Dir. If Name does
376 not exist, it adds the new directory Dir last in the code path.
377 The new directory must also be named .../Name[-Vsn][/ebin]. This
378 function is to be used if a new version of the directory
379 (library) is added to a running system.
380 Returns:
382 true:
384 If successful
385 {error, bad_name}:
387 If Name is not found
388 {error, bad_directory}:
390 If Dir does not exist
391 {error, {badarg, [Name, Dir]}}:
393 If Name or Dir is invalid
394 load_file(Module) -> load_ret()
396 Types:
398 Module = module()
400 load_ret() =
401 {error, What :: load_error_rsn()} |
402 {module, Module :: module()}
403 Tries to load the Erlang module Module, using the code path. It
405 looks for the object code file with an extension corresponding
406 to the Erlang machine used, for example, Module.beam. The load‐
407 ing fails if the module name found in the object code differs
408 from the name Module. load_binary/3 must be used to load object
409 code with a module name that is different from the file name.
410 Returns {module, Module} if successful, or {error, Reason} if
412 loading fails. See Error Reasons for Code-Loading Functions for
413 a description of the possible error reasons.
414 load_abs(Filename) -> load_ret()
416 Types:
418 Filename = file:filename()
420 load_ret() =
421 {error, What :: load_error_rsn()} |
422 {module, Module :: module()}
423 loaded_filename() =
424 (Filename :: file:filename()) | loaded_ret_atoms()
425 loaded_ret_atoms() = cover_compiled | preloaded
426 Same as load_file(Module), but Filename is an absolute or rela‐
428 tive filename. The code path is not searched. It returns a value
429 in the same way as load_file/1. Notice that Filename must not
430 contain the extension (for example, .beam) because load_abs/1
431 adds the correct extension.
432 ensure_loaded(Module) -> {module, Module} | {error, What}
434 Types:
436 Module = module()
438 What = embedded | badfile | nofile | on_load_failure
439 Tries to load a module in the same way as load_file/1, unless
441 the module is already loaded. However, in embedded mode it does
442 not load a module that is not already loaded, but returns
443 {error, embedded} instead. See Error Reasons for Code-Loading
444 Functions for a description of other possible error reasons.
445 load_binary(Module, Filename, Binary) ->
447 {module, Module} | {error, What}
448 Types:
450 Module = module()
452 Filename = loaded_filename()
453 Binary = binary()
454 What = badarg | load_error_rsn()
455 loaded_filename() =
456 (Filename :: file:filename()) | loaded_ret_atoms()
457 loaded_ret_atoms() = cover_compiled | preloaded
458 This function can be used to load object code on remote Erlang
460 nodes. Argument Binary must contain object code for Module.
461 Filename is only used by the code server to keep a record of
462 from which file the object code for Module comes. Thus, Filename
463 is not opened and read by the code server.
464 Returns {module, Module} if successful, or {error, Reason} if
466 loading fails. See Error Reasons for Code-Loading Functions for
467 a description of the possible error reasons.
468 atomic_load(Modules) -> ok | {error, [{Module, What}]}
470 Types:
472 Modules = [Module | {Module, Filename, Binary}]
474 Module = module()
475 Filename = file:filename()
476 Binary = binary()
477 What =
478 badfile |
479 nofile |
480 on_load_not_allowed |
481 duplicated |
482 not_purged |
483 sticky_directory |
484 pending_on_load
485 Tries to load all of the modules in the list Modules atomically.
487 That means that either all modules are loaded at the same time,
488 or none of the modules are loaded if there is a problem with any
489 of the modules.
490 Loading can fail for one the following reasons:
492 badfile:
494 The object code has an incorrect format or the module name
495 in the object code is not the expected module name.
496 nofile:
498 No file with object code exists.
499 on_load_not_allowed:
501 A module contains an -on_load function.
502 duplicated:
504 A module is included more than once in Modules.
505 not_purged:
507 The object code can not be loaded because an old version of
508 the code already exists.
509 sticky_directory:
511 The object code resides in a sticky directory.
512 pending_on_load:
514 A previously loaded module contains an -on_load function
515 that never finished.
516 If it is important to minimize the time that an application is
518 inactive while changing code, use prepare_loading/1 and fin‐
519 ish_loading/1 instead of atomic_load/1. Here is an example:
520 {ok,Prepared} = code:prepare_loading(Modules),
522 %% Put the application into an inactive state or do any
523 %% other preparation needed before changing the code.
524 ok = code:finish_loading(Prepared),
525 %% Resume the application.
526 prepare_loading(Modules) ->
528 {ok, Prepared} | {error, [{Module, What}]}
529 Types:
531 Modules = [Module | {Module, Filename, Binary}]
533 Module = module()
534 Filename = file:filename()
535 Binary = binary()
536 Prepared = prepared_code()
537 What = badfile | nofile | on_load_not_allowed | duplicated
538 Prepares to load the modules in the list Modules. Finish the
540 loading by calling finish_loading(Prepared).
541 This function can fail with one of the following error reasons:
543 badfile:
545 The object code has an incorrect format or the module name
546 in the object code is not the expected module name.
547 nofile:
549 No file with object code exists.
550 on_load_not_allowed:
552 A module contains an -on_load function.
553 duplicated:
555 A module is included more than once in Modules.
556 finish_loading(Prepared) -> ok | {error, [{Module, What}]}
558 Types:
560 Prepared = prepared_code()
562 Module = module()
563 What = not_purged | sticky_directory | pending_on_load
564 Tries to load code for all modules that have been previously
566 prepared by prepare_loading/1. The loading occurs atomically,
567 meaning that either all modules are loaded at the same time, or
568 none of the modules are loaded.
569 This function can fail with one of the following error reasons:
571 not_purged:
573 The object code can not be loaded because an old version of
574 the code already exists.
575 sticky_directory:
577 The object code resides in a sticky directory.
578 pending_on_load:
580 A previously loaded module contains an -on_load function
581 that never finished.
582 ensure_modules_loaded(Modules :: [Module]) ->
584 ok | {error, [{Module, What}]}
585 Types:
587 Module = module()
589 What = badfile | nofile | on_load_failure
590 Tries to load any modules not already loaded in the list Modules
592 in the same way as load_file/1.
593 Returns ok if successful, or {error,[{Module,Reason}]} if load‐
595 ing of some modules fails. See Error Reasons for Code-Loading
596 Functions for a description of other possible error reasons.
597 delete(Module) -> boolean()
599 Types:
601 Module = module()
603 Removes the current code for Module, that is, the current code
605 for Module is made old. This means that processes can continue
606 to execute the code in the module, but no external function
607 calls can be made to it.
608 Returns true if successful, or false if there is old code for
610 Module that must be purged first, or if Module is not a (loaded)
611 module.
612 purge(Module) -> boolean()
614 Types:
616 Module = module()
618 Purges the code for Module, that is, removes code marked as old.
620 If some processes still linger in the old code, these processes
621 are killed before the code is removed.
622 Note:
624 As of ERTS version 9.0, a process is only considered to be lin‐
625 gering in the code if it has direct references to the code. For
626 more information see documentation of
627 erlang:check_process_code/3, which is used in order to determine
628 this.
629 Returns true if successful and any process is needed to be
632 killed, otherwise false.
633 soft_purge(Module) -> boolean()
635 Types:
637 Module = module()
639 Purges the code for Module, that is, removes code marked as old,
641 but only if no processes linger in it.
642 Note:
644 As of ERTS version 9.0, a process is only considered to be lin‐
645 gering in the code if it has direct references to the code. For
646 more information see documentation of
647 erlang:check_process_code/3, which is used in order to determine
648 this.
649 Returns false if the module cannot be purged because of pro‐
652 cesses lingering in old code, otherwise true.
653 is_loaded(Module) -> {file, Loaded} | false
655 Types:
657 Module = module()
659 Loaded = loaded_filename()
660 loaded_filename() =
661 (Filename :: file:filename()) | loaded_ret_atoms()
662 Filename is an absolute filename.
663 loaded_ret_atoms() = cover_compiled | preloaded
664 Checks if Module is loaded. If it is, {file, Loaded} is
666 returned, otherwise false.
667 Normally, Loaded is the absolute filename Filename from which
669 the code is obtained. If the module is preloaded (see
670 script(4)), Loaded==preloaded. If the module is Cover-compiled
671 (see cover(3)), Loaded==cover_compiled.
672 all_loaded() -> [{Module, Loaded}]
674 Types:
676 Module = module()
678 Loaded = loaded_filename()
679 loaded_filename() =
680 (Filename :: file:filename()) | loaded_ret_atoms()
681 Filename is an absolute filename.
682 loaded_ret_atoms() = cover_compiled | preloaded
683 Returns a list of tuples {Module, Loaded} for all loaded mod‐
685 ules. Loaded is normally the absolute filename, as described for
686 is_loaded/1.
687 which(Module) -> Which
689 Types:
691 Module = module()
693 Which = file:filename() | loaded_ret_atoms() | non_existing
694 loaded_ret_atoms() = cover_compiled | preloaded
695 If the module is not loaded, this function searches the code
697 path for the first file containing object code for Module and
698 returns the absolute filename.
699 If the module is loaded, it returns the name of the file con‐
701 taining the loaded object code.
702 If the module is preloaded, preloaded is returned.
704 If the module is Cover-compiled, cover_compiled is returned.
706 If the module cannot be found, non_existing is returned.
708 get_object_code(Module) -> {Module, Binary, Filename} | error
710 Types:
712 Module = module()
714 Binary = binary()
715 Filename = file:filename()
716 Searches the code path for the object code of module Module.
718 Returns {Module, Binary, Filename} if successful, otherwise
719 error. Binary is a binary data object, which contains the object
720 code for the module. This can be useful if code is to be loaded
721 on a remote node in a distributed system. For example, loading
722 module Module on a node Node is done as follows:
723 {_Module, Binary, Filename} = code:get_object_code(Module),
725 rpc:call(Node, code, load_binary, [Module, Filename, Binary]),
726 root_dir() -> file:filename()
728 Returns the root directory of Erlang/OTP, which is the directory
730 where it is installed.
731 Example:
733 > code:root_dir().
735 "/usr/local/otp"
736 lib_dir() -> file:filename()
738 Returns the library directory, $OTPROOT/lib, where $OTPROOT is
740 the root directory of Erlang/OTP.
741 Example:
743 > code:lib_dir().
745 "/usr/local/otp/lib"
746 lib_dir(Name) -> file:filename() | {error, bad_name}
748 Types:
750 Name = atom()
752 Returns the path for the "library directory", the top directory,
754 for an application Name located under $OTPROOT/lib or on a
755 directory referred to with environment variable ERL_LIBS.
756 If a regular directory called Name or Name-Vsn exists in the
758 code path with an ebin subdirectory, the path to this directory
759 is returned (not the ebin directory).
760 If the directory refers to a directory in an archive, the ar‐
762 chive name is stripped away before the path is returned. For
763 example, if directory /usr/local/otp/lib/mnesia-4.2.2.ez/mne‐
764 sia-4.2.2/ebin is in the path, /usr/local/otp/lib/mne‐
765 sia-4.2.2/ebin is returned. This means that the library direc‐
766 tory for an application is the same, regardless if the applica‐
767 tion resides in an archive or not.
768 Example:
770 > code:lib_dir(mnesia).
772 "/usr/local/otp/lib/mnesia-4.2.2"
773 Returns {error, bad_name} if Name is not the name of an applica‐
775 tion under $OTPROOT/lib or on a directory referred to through
776 environment variable ERL_LIBS. Fails with an exception if Name
777 has the wrong type.
778 Warning:
780 For backward compatibility, Name is also allowed to be a string.
781 That will probably change in a future release.
782 lib_dir(Name, SubDir) -> file:filename() | {error, bad_name}
785 Types:
787 Name = SubDir = atom()
789 Returns the path to a subdirectory directly under the top direc‐
791 tory of an application. Normally the subdirectories reside under
792 the top directory for the application, but when applications at
793 least partly resides in an archive, the situation is different.
794 Some of the subdirectories can reside as regular directories
795 while other reside in an archive file. It is not checked whether
796 this directory exists.
797 Example:
799 > code:lib_dir(megaco, priv).
801 "/usr/local/otp/lib/megaco-3.9.1.1/priv"
802 Fails with an exception if Name or SubDir has the wrong type.
804 compiler_dir() -> file:filename()
806 Returns the compiler library directory. Equivalent to
808 code:lib_dir(compiler).
809 priv_dir(Name) -> file:filename() | {error, bad_name}
811 Types:
813 Name = atom()
815 Returns the path to the priv directory in an application. Equiv‐
817 alent to code:lib_dir(Name, priv).
818 Warning:
820 For backward compatibility, Name is also allowed to be a string.
821 That will probably change in a future release.
822 objfile_extension() -> nonempty_string()
825 Returns the object code file extension corresponding to the
827 Erlang machine used, namely .beam.
828 stick_dir(Dir) -> ok | error
830 Types:
832 Dir = file:filename()
834 Marks Dir as sticky.
836 Returns ok if successful, otherwise error.
838 unstick_dir(Dir) -> ok | error
840 Types:
842 Dir = file:filename()
844 Unsticks a directory that is marked as sticky.
846 Returns ok if successful, otherwise error.
848 is_sticky(Module) -> boolean()
850 Types:
852 Module = module()
854 Returns true if Module is the name of a module that has been
856 loaded from a sticky directory (in other words: an attempt to
857 reload the module will fail), or false if Module is not a loaded
858 module or is not sticky.
859 where_is_file(Filename) -> non_existing | Absname
861 Types:
863 Filename = Absname = file:filename()
865 Searches the code path for Filename, a file of arbitrary type.
867 If found, the full name is returned. non_existing is returned if
868 the file cannot be found. The function can be useful, for exam‐
869 ple, to locate application resource files.
870 clash() -> ok
872 Searches all directories in the code path for module names with
874 identical names and writes a report to stdout.
875 module_status(Module :: module()) ->
877 not_loaded | loaded | modified | removed
878 Returns:
880 not_loaded:
882 If Module is not currently loaded.
883 loaded:
885 If Module is loaded and the object file exists and contains
886 the same code.
887 removed:
889 If Module is loaded but no corresponding object file can be
890 found in the code path.
891 modified:
893 If Module is loaded but the object file contains code with a
894 different MD5 checksum.
895 Preloaded modules are always reported as loaded, without
897 inspecting the contents on disk. Cover compiled modules will
898 always be reported as modified if an object file exists, or as
899 removed otherwise. Modules whose load path is an empty string
900 (which is the convention for auto-generated code) will only be
901 reported as loaded or not_loaded.
902 For modules that have native code loaded (see is_mod‐
904 ule_native/1), the MD5 sum of the native code in the object file
905 is used for the comparison, if it exists; the Beam code in the
906 file is ignored. Reversely, for modules that do not currently
907 have native code loaded, any native code in the file will be
908 ignored.
909 See also modified_modules/0.
911 modified_modules() -> [module()]
913 Returns the list of all currently loaded modules for which mod‐
915 ule_status/1 returns modified. See also all_loaded/0.
916 is_module_native(Module) -> true | false | undefined
918 Types:
920 Module = module()
922 Returns:
924 true:
926 If Module is the name of a loaded module that has native
927 code loaded
928 false:
930 If Module is loaded but does not have native code
931 undefined:
933 If Module is not loaded
934 get_mode() -> embedded | interactive
936 Returns an atom describing the mode of the code server: interac‐
938 tive or embedded.
939 This information is useful when an external entity (for example,
941 an IDE) provides additional code for a running node. If the code
942 server is in interactive mode, it only has to add the path to
943 the code. If the code server is in embedded mode, the code must
944 be loaded with load_binary/3.
945Ericsson AB kernel 5.4.3.2 code(3)