1code(3) Erlang Module Definition code(3)
2
3
4
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
13 The runtime system can be started in interactive or embedded mode.
14 Which one is decided by the command-line flag -mode:
15
16 % erl -mode interactive
17
18 The modes are as follows:
19
20 * 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
27 * 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
33 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
36 request 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
44 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
53 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
56 directories without an ebin directory are ignored.
57
58 All application directories found in the additional directories appears
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
65 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
69 Example:
70
71 On a Unix-like system, ERL_LIBS can be set to the following
72
73 /usr/local/jungerl:/home/some_user/my_erlang_lib
74
75 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
85
86 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
90 Erlang archive files can contain entire Erlang applications or parts of
91 applications. The structure in an archive file is the same as the
92 directory 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
98 An archive file for an application can, for example, be created like
99 this:
100
101 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
107 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
111 Normally the top directory of an application is located in library
112 directory $OTPROOT/lib or in a directory referred to by environment
113 variable ERL_LIBS. At startup, when the initial code path is computed,
114 the code server also looks for archive files in these directories and
115 possibly adds ebin directories in archives to the code path. The code
116 path then contains paths to directories that look like $OTP‐
117 ROOT/lib/mnesia.ez/mnesia/ebin or $OTPROOT/lib/mnesia-4.4.7.ez/mne‐
118 sia-4.4.7/ebin.
119
120 The code server uses module erl_prim_loader in ERTS (possibly through
121 erl_boot_server) to read code files from archives. However, the func‐
122 tions in erl_prim_loader can also be used by other applications to read
123 files from archives. For example, the call erl_prim_loader:list_dir(
124 "/otp/root/lib/mnesia-4.4.7.ez/mnesia-4.4.7/examples/bench)" would list
125 the contents of a directory inside an archive. See erl_prim_loader(3).
126
127 An application archive file and a regular application directory can
128 coexist. This can be useful when it is needed to have parts of the
129 application as regular files. A typical case is the priv directory,
130 which must reside as a regular directory to link in drivers dynamically
131 and start port programs. For other applications that do not need this,
132 directory priv can reside in the archive and the files under the direc‐
133 tory priv can be read through erl_prim_loader.
134
135 When a directory is added to the code path and when the entire code
136 path is (re)set, the code server decides which subdirectories in an
137 application that are to be read from the archive and which that are to
138 be read as regular files. If directories are added or removed after‐
139 wards, the file access can fail if the code path is not updated (possi‐
140 bly to the same path as before, to trigger the directory resolution
141 update).
142
143 For each directory on the second level in the application archive
144 (ebin, priv, src, and so on), the code server first chooses the regular
145 directory if it exists and second from the archive. Function
146 code:lib_dir/2 returns the path to the subdirectory. For example,
147 code:lib_dir(megaco,ebin) can return
148 /otp/root/lib/megaco-3.9.1.1.ez/megaco-3.9.1.1/ebin while
149 code:lib_dir(megaco,priv) can return /otp/root/lib/megaco-3.9.1.1/priv.
150
151 When an escript file contains an archive, there are no restrictions on
152 the name of the escript and no restrictions on how many applications
153 that can be stored in the embedded archive. Single Beam files can also
154 reside on the top level in the archive. At startup, the top directory
155 in the embedded archive and all (second level) ebin directories in the
156 embedded archive are added to the code path. See erts:escript(1).
157
158 When the choice of directories in the code path is strict, the direc‐
159 tory that ends up in the code path is exactly the stated one. This
160 means that if, for example, the directory $OTPROOT/lib/mne‐
161 sia-4.4.7/ebin is explicitly added to the code path, the code server
162 does not load files from $OTPROOT/lib/mnesia-4.4.7.ez/mne‐
163 sia-4.4.7/ebin.
164
165 This behavior can be controlled through command-line flag
166 -code_path_choice Choice. If the flag is set to relaxed, the code
167 server instead chooses a suitable directory depending on the actual
168 file structure. If a regular application ebin directory exists, it is
169 chosen. Otherwise, the directory ebin in the archive is chosen if it
170 exists. If neither of them exists, the original directory is chosen.
171
172 Command-line flag -code_path_choice Choice also affects how module init
173 interprets the boot script. The interpretation of the explicit code
174 paths in the boot script can be strict or relaxed. It is particularly
175 useful to set the flag to relaxed when elaborating with code loading
176 from archives without editing the boot script. The default is relaxed.
177 See erts:init(3).
178
180 The code for a module can exist in two variants in a system: current
181 code and old code. When a module is loaded into the system for the
182 first time, the module code becomes 'current' and the global export ta‐
183 ble is updated with references to all functions exported from the mod‐
184 ule.
185
186 If then a new instance of the module is loaded (for example, because of
187 error correction), the code of the previous instance becomes 'old', and
188 all export entries referring to the previous instance are removed.
189 After that, the new instance is loaded as for the first time, and
190 becomes 'current'.
191
192 Both old and current code for a module are valid, and can even be eval‐
193 uated concurrently. The difference is that exported functions in old
194 code are unavailable. Hence, a global call cannot be made to an
195 exported function in old code, but old code can still be evaluated
196 because of processes lingering in it.
197
198 If a third instance of the module is loaded, the code server removes
199 (purges) the old code and any processes lingering in it are terminated.
200 Then the third instance becomes 'current' and the previously current
201 code becomes 'old'.
202
203 For more information about old and current code, and how to make a
204 process switch from old to current code, see section Compilation and
205 Code Loading in the Erlang Reference Manual.
206
208 Module and application names are atoms, while file and directory names
209 are strings. For backward compatibility reasons, some functions accept
210 both strings and atoms, but a future release will probably only allow
211 the arguments that are documented.
212
213 Functions in this module generally fail with an exception if they are
214 passed an incorrect type (for example, an integer or a tuple where an
215 atom is expected). An error tuple is returned if the argument type is
216 correct, but there are some other errors (for example, a non-existing
217 directory is specified to set_path/1).
218
220 Functions that load code (such as load_file/1) will return {error,Rea‐
221 son} if the load operation fails. Here follows a description of the
222 common reasons.
223
224 badfile:
225 The object code has an incorrect format or the module name in the
226 object code is not the expected module name.
227
228 nofile:
229 No file with object code was found.
230
231 not_purged:
232 The object code could not be loaded because an old version of the
233 code already existed.
234
235 on_load_failure:
236 The module has an -on_load function that failed when it was called.
237
238 sticky_directory:
239 The object code resides in a sticky directory.
240
242 load_ret() =
243 {error, What :: load_error_rsn()} |
244 {module, Module :: module()}
245
246 load_error_rsn() =
247 badfile |
248 nofile |
249 not_purged |
250 on_load_failure |
251 sticky_directory
252
253 prepared_code()
254
255 An opaque term holding prepared code.
256
258 set_path(Path) -> true | {error, What}
259
260 Types:
261
262 Path = [Dir :: file:filename()]
263 What = bad_directory
264
265 Sets the code path to the list of directories Path.
266
267 Returns:
268
269 true:
270 If successful
271
272 {error, bad_directory}:
273 If any Dir is not a directory name
274
275 get_path() -> Path
276
277 Types:
278
279 Path = [Dir :: file:filename()]
280
281 Returns the code path.
282
283 add_path(Dir) -> add_path_ret()
284
285 add_pathz(Dir) -> add_path_ret()
286
287 Types:
288
289 Dir = file:filename()
290 add_path_ret() = true | {error, bad_directory}
291
292 Adds Dir to the code path. The directory is added as the last
293 directory in the new path. If Dir already exists in the path, it
294 is not added.
295
296 Returns true if successful, or {error, bad_directory} if Dir is
297 not the name of a directory.
298
299 add_patha(Dir) -> add_path_ret()
300
301 Types:
302
303 Dir = file:filename()
304 add_path_ret() = true | {error, bad_directory}
305
306 Adds Dir to the beginning of the code path. If Dir exists, it is
307 removed from the old position in the code path.
308
309 Returns true if successful, or {error, bad_directory} if Dir is
310 not the name of a directory.
311
312 add_paths(Dirs) -> ok
313
314 add_pathsz(Dirs) -> ok
315
316 Types:
317
318 Dirs = [Dir :: file:filename()]
319
320 Adds the directories in Dirs to the end of the code path. If a
321 Dir exists, it is not added.
322
323 Always returns ok, regardless of the validity of each individual
324 Dir.
325
326 add_pathsa(Dirs) -> ok
327
328 Types:
329
330 Dirs = [Dir :: file:filename()]
331
332 Traverses Dirs and adds each Dir to the beginning of the code
333 path. This means that the order of Dirs is reversed in the
334 resulting code path. For example, if you add [Dir1,Dir2], the
335 resulting path will be [Dir2,Dir1|OldCodePath].
336
337 If a Dir already exists in the code path, it is removed from the
338 old position.
339
340 Always returns ok, regardless of the validity of each individual
341 Dir.
342
343 del_path(NameOrDir) -> boolean() | {error, What}
344
345 Types:
346
347 NameOrDir = Name | Dir
348 Name = atom()
349 Dir = file:filename()
350 What = bad_name
351
352 Deletes a directory from the code path. The argument can be an
353 atom Name, in which case the directory with the name
354 .../Name[-Vsn][/ebin] is deleted from the code path. Also, the
355 complete directory name Dir can be specified as argument.
356
357 Returns:
358
359 true:
360 If successful
361
362 false:
363 If the directory is not found
364
365 {error, bad_name}:
366 If the argument is invalid
367
368 replace_path(Name, Dir) -> true | {error, What}
369
370 Types:
371
372 Name = atom()
373 Dir = file:filename()
374 What = bad_directory | bad_name | {badarg, term()}
375
376 Replaces an old occurrence of a directory named
377 .../Name[-Vsn][/ebin] in the code path, with Dir. If Name does
378 not exist, it adds the new directory Dir last in the code path.
379 The new directory must also be named .../Name[-Vsn][/ebin]. This
380 function is to be used if a new version of the directory
381 (library) is added to a running system.
382
383 Returns:
384
385 true:
386 If successful
387
388 {error, bad_name}:
389 If Name is not found
390
391 {error, bad_directory}:
392 If Dir does not exist
393
394 {error, {badarg, [Name, Dir]}}:
395 If Name or Dir is invalid
396
397 load_file(Module) -> load_ret()
398
399 Types:
400
401 Module = module()
402 load_ret() =
403 {error, What :: load_error_rsn()} |
404 {module, Module :: module()}
405
406 Tries to load the Erlang module Module, using the code path. It
407 looks for the object code file with an extension corresponding
408 to the Erlang machine used, for example, Module.beam. The load‐
409 ing fails if the module name found in the object code differs
410 from the name Module. load_binary/3 must be used to load object
411 code with a module name that is different from the file name.
412
413 Returns {module, Module} if successful, or {error, Reason} if
414 loading fails. See Error Reasons for Code-Loading Functions for
415 a description of the possible error reasons.
416
417 load_abs(Filename) -> load_ret()
418
419 Types:
420
421 Filename = file:filename()
422 load_ret() =
423 {error, What :: load_error_rsn()} |
424 {module, Module :: module()}
425 loaded_filename() =
426 (Filename :: file:filename()) | loaded_ret_atoms()
427 loaded_ret_atoms() = cover_compiled | preloaded
428
429 Same as load_file(Module), but Filename is an absolute or rela‐
430 tive filename. The code path is not searched. It returns a value
431 in the same way as load_file/1. Notice that Filename must not
432 contain the extension (for example, .beam) because load_abs/1
433 adds the correct extension.
434
435 ensure_loaded(Module) -> {module, Module} | {error, What}
436
437 Types:
438
439 Module = module()
440 What = embedded | badfile | nofile | on_load_failure
441
442 Tries to load a module in the same way as load_file/1, unless
443 the module is already loaded. However, in embedded mode it does
444 not load a module that is not already loaded, but returns
445 {error, embedded} instead. See Error Reasons for Code-Loading
446 Functions for a description of other possible error reasons.
447
448 load_binary(Module, Filename, Binary) ->
449 {module, Module} | {error, What}
450
451 Types:
452
453 Module = module()
454 Filename = loaded_filename()
455 Binary = binary()
456 What = badarg | load_error_rsn()
457 loaded_filename() =
458 (Filename :: file:filename()) | loaded_ret_atoms()
459 loaded_ret_atoms() = cover_compiled | preloaded
460
461 This function can be used to load object code on remote Erlang
462 nodes. Argument Binary must contain object code for Module.
463 Filename is only used by the code server to keep a record of
464 from which file the object code for Module comes. Thus, Filename
465 is not opened and read by the code server.
466
467 Returns {module, Module} if successful, or {error, Reason} if
468 loading fails. See Error Reasons for Code-Loading Functions for
469 a description of the possible error reasons.
470
471 atomic_load(Modules) -> ok | {error, [{Module, What}]}
472
473 Types:
474
475 Modules = [Module | {Module, Filename, Binary}]
476 Module = module()
477 Filename = file:filename()
478 Binary = binary()
479 What =
480 badfile |
481 nofile |
482 on_load_not_allowed |
483 duplicated |
484 not_purged |
485 sticky_directory |
486 pending_on_load
487
488 Tries to load all of the modules in the list Modules atomically.
489 That means that either all modules are loaded at the same time,
490 or none of the modules are loaded if there is a problem with any
491 of the modules.
492
493 Loading can fail for one the following reasons:
494
495 badfile:
496 The object code has an incorrect format or the module name
497 in the object code is not the expected module name.
498
499 nofile:
500 No file with object code exists.
501
502 on_load_not_allowed:
503 A module contains an -on_load function.
504
505 duplicated:
506 A module is included more than once in Modules.
507
508 not_purged:
509 The object code can not be loaded because an old version of
510 the code already exists.
511
512 sticky_directory:
513 The object code resides in a sticky directory.
514
515 pending_on_load:
516 A previously loaded module contains an -on_load function
517 that never finished.
518
519 If it is important to minimize the time that an application is
520 inactive while changing code, use prepare_loading/1 and fin‐
521 ish_loading/1 instead of atomic_load/1. Here is an example:
522
523 {ok,Prepared} = code:prepare_loading(Modules),
524 %% Put the application into an inactive state or do any
525 %% other preparation needed before changing the code.
526 ok = code:finish_loading(Prepared),
527 %% Resume the application.
528
529 prepare_loading(Modules) ->
530 {ok, Prepared} | {error, [{Module, What}]}
531
532 Types:
533
534 Modules = [Module | {Module, Filename, Binary}]
535 Module = module()
536 Filename = file:filename()
537 Binary = binary()
538 Prepared = prepared_code()
539 What = badfile | nofile | on_load_not_allowed | duplicated
540
541 Prepares to load the modules in the list Modules. Finish the
542 loading by calling finish_loading(Prepared).
543
544 This function can fail with one of the following error reasons:
545
546 badfile:
547 The object code has an incorrect format or the module name
548 in the object code is not the expected module name.
549
550 nofile:
551 No file with object code exists.
552
553 on_load_not_allowed:
554 A module contains an -on_load function.
555
556 duplicated:
557 A module is included more than once in Modules.
558
559 finish_loading(Prepared) -> ok | {error, [{Module, What}]}
560
561 Types:
562
563 Prepared = prepared_code()
564 Module = module()
565 What = not_purged | sticky_directory | pending_on_load
566
567 Tries to load code for all modules that have been previously
568 prepared by prepare_loading/1. The loading occurs atomically,
569 meaning that either all modules are loaded at the same time, or
570 none of the modules are loaded.
571
572 This function can fail with one of the following error reasons:
573
574 not_purged:
575 The object code can not be loaded because an old version of
576 the code already exists.
577
578 sticky_directory:
579 The object code resides in a sticky directory.
580
581 pending_on_load:
582 A previously loaded module contains an -on_load function
583 that never finished.
584
585 ensure_modules_loaded(Modules :: [Module]) ->
586 ok | {error, [{Module, What}]}
587
588 Types:
589
590 Module = module()
591 What = badfile | nofile | on_load_failure
592
593 Tries to load any modules not already loaded in the list Modules
594 in the same way as load_file/1.
595
596 Returns ok if successful, or {error,[{Module,Reason}]} if load‐
597 ing of some modules fails. See Error Reasons for Code-Loading
598 Functions for a description of other possible error reasons.
599
600 delete(Module) -> boolean()
601
602 Types:
603
604 Module = module()
605
606 Removes the current code for Module, that is, the current code
607 for Module is made old. This means that processes can continue
608 to execute the code in the module, but no external function
609 calls can be made to it.
610
611 Returns true if successful, or false if there is old code for
612 Module that must be purged first, or if Module is not a (loaded)
613 module.
614
615 purge(Module) -> boolean()
616
617 Types:
618
619 Module = module()
620
621 Purges the code for Module, that is, removes code marked as old.
622 If some processes still linger in the old code, these processes
623 are killed before the code is removed.
624
625 Note:
626 As of ERTS version 9.0, a process is only considered to be lin‐
627 gering in the code if it has direct references to the code. For
628 more information see documentation of
629 erlang:check_process_code/3, which is used in order to determine
630 this.
631
632
633 Returns true if successful and any process is needed to be
634 killed, otherwise false.
635
636 soft_purge(Module) -> boolean()
637
638 Types:
639
640 Module = module()
641
642 Purges the code for Module, that is, removes code marked as old,
643 but only if no processes linger in it.
644
645 Note:
646 As of ERTS version 9.0, a process is only considered to be lin‐
647 gering in the code if it has direct references to the code. For
648 more information see documentation of
649 erlang:check_process_code/3, which is used in order to determine
650 this.
651
652
653 Returns false if the module cannot be purged because of pro‐
654 cesses lingering in old code, otherwise true.
655
656 is_loaded(Module) -> {file, Loaded} | false
657
658 Types:
659
660 Module = module()
661 Loaded = loaded_filename()
662 loaded_filename() =
663 (Filename :: file:filename()) | loaded_ret_atoms()
664 Filename is an absolute filename.
665 loaded_ret_atoms() = cover_compiled | preloaded
666
667 Checks if Module is loaded. If it is, {file, Loaded} is
668 returned, otherwise false.
669
670 Normally, Loaded is the absolute filename Filename from which
671 the code is obtained. If the module is preloaded (see
672 script(4)), Loaded==preloaded. If the module is Cover-compiled
673 (see cover(3)), Loaded==cover_compiled.
674
675 all_loaded() -> [{Module, Loaded}]
676
677 Types:
678
679 Module = module()
680 Loaded = loaded_filename()
681 loaded_filename() =
682 (Filename :: file:filename()) | loaded_ret_atoms()
683 Filename is an absolute filename.
684 loaded_ret_atoms() = cover_compiled | preloaded
685
686 Returns a list of tuples {Module, Loaded} for all loaded mod‐
687 ules. Loaded is normally the absolute filename, as described for
688 is_loaded/1.
689
690 which(Module) -> Which
691
692 Types:
693
694 Module = module()
695 Which = file:filename() | loaded_ret_atoms() | non_existing
696 loaded_ret_atoms() = cover_compiled | preloaded
697
698 If the module is not loaded, this function searches the code
699 path for the first file containing object code for Module and
700 returns the absolute filename.
701
702 If the module is loaded, it returns the name of the file con‐
703 taining the loaded object code.
704
705 If the module is preloaded, preloaded is returned.
706
707 If the module is Cover-compiled, cover_compiled is returned.
708
709 If the module cannot be found, non_existing is returned.
710
711 get_object_code(Module) -> {Module, Binary, Filename} | error
712
713 Types:
714
715 Module = module()
716 Binary = binary()
717 Filename = file:filename()
718
719 Searches the code path for the object code of module Module.
720 Returns {Module, Binary, Filename} if successful, otherwise
721 error. Binary is a binary data object, which contains the object
722 code for the module. This can be useful if code is to be loaded
723 on a remote node in a distributed system. For example, loading
724 module Module on a node Node is done as follows:
725
726 {_Module, Binary, Filename} = code:get_object_code(Module),
727 rpc:call(Node, code, load_binary, [Module, Filename, Binary]),
728
729 root_dir() -> file:filename()
730
731 Returns the root directory of Erlang/OTP, which is the directory
732 where it is installed.
733
734 Example:
735
736 > code:root_dir().
737 "/usr/local/otp"
738
739 lib_dir() -> file:filename()
740
741 Returns the library directory, $OTPROOT/lib, where $OTPROOT is
742 the root directory of Erlang/OTP.
743
744 Example:
745
746 > code:lib_dir().
747 "/usr/local/otp/lib"
748
749 lib_dir(Name) -> file:filename() | {error, bad_name}
750
751 Types:
752
753 Name = atom()
754
755 Returns the path for the "library directory", the top directory,
756 for an application Name located under $OTPROOT/lib or on a
757 directory referred to with environment variable ERL_LIBS.
758
759 If a regular directory called Name or Name-Vsn exists in the
760 code path with an ebin subdirectory, the path to this directory
761 is returned (not the ebin directory).
762
763 If the directory refers to a directory in an archive, the ar‐
764 chive name is stripped away before the path is returned. For
765 example, if directory /usr/local/otp/lib/mnesia-4.2.2.ez/mne‐
766 sia-4.2.2/ebin is in the path, /usr/local/otp/lib/mne‐
767 sia-4.2.2/ebin is returned. This means that the library direc‐
768 tory for an application is the same, regardless if the applica‐
769 tion resides in an archive or not.
770
771 Example:
772
773 > code:lib_dir(mnesia).
774 "/usr/local/otp/lib/mnesia-4.2.2"
775
776 Returns {error, bad_name} if Name is not the name of an applica‐
777 tion under $OTPROOT/lib or on a directory referred to through
778 environment variable ERL_LIBS. Fails with an exception if Name
779 has the wrong type.
780
781 Warning:
782 For backward compatibility, Name is also allowed to be a string.
783 That will probably change in a future release.
784
785
786 lib_dir(Name, SubDir) -> file:filename() | {error, bad_name}
787
788 Types:
789
790 Name = SubDir = atom()
791
792 Returns the path to a subdirectory directly under the top direc‐
793 tory of an application. Normally the subdirectories reside under
794 the top directory for the application, but when applications at
795 least partly resides in an archive, the situation is different.
796 Some of the subdirectories can reside as regular directories
797 while other reside in an archive file. It is not checked whether
798 this directory exists.
799
800 Example:
801
802 > code:lib_dir(megaco, priv).
803 "/usr/local/otp/lib/megaco-3.9.1.1/priv"
804
805 Fails with an exception if Name or SubDir has the wrong type.
806
807 compiler_dir() -> file:filename()
808
809 Returns the compiler library directory. Equivalent to
810 code:lib_dir(compiler).
811
812 priv_dir(Name) -> file:filename() | {error, bad_name}
813
814 Types:
815
816 Name = atom()
817
818 Returns the path to the priv directory in an application. Equiv‐
819 alent to code:lib_dir(Name, priv).
820
821 Warning:
822 For backward compatibility, Name is also allowed to be a string.
823 That will probably change in a future release.
824
825
826 objfile_extension() -> nonempty_string()
827
828 Returns the object code file extension corresponding to the
829 Erlang machine used, namely .beam.
830
831 stick_dir(Dir) -> ok | error
832
833 Types:
834
835 Dir = file:filename()
836
837 Marks Dir as sticky.
838
839 Returns ok if successful, otherwise error.
840
841 unstick_dir(Dir) -> ok | error
842
843 Types:
844
845 Dir = file:filename()
846
847 Unsticks a directory that is marked as sticky.
848
849 Returns ok if successful, otherwise error.
850
851 is_sticky(Module) -> boolean()
852
853 Types:
854
855 Module = module()
856
857 Returns true if Module is the name of a module that has been
858 loaded from a sticky directory (in other words: an attempt to
859 reload the module will fail), or false if Module is not a loaded
860 module or is not sticky.
861
862 where_is_file(Filename) -> non_existing | Absname
863
864 Types:
865
866 Filename = Absname = file:filename()
867
868 Searches the code path for Filename, a file of arbitrary type.
869 If found, the full name is returned. non_existing is returned if
870 the file cannot be found. The function can be useful, for exam‐
871 ple, to locate application resource files.
872
873 clash() -> ok
874
875 Searches all directories in the code path for module names with
876 identical names and writes a report to stdout.
877
878 module_status(Module :: module()) ->
879 not_loaded | loaded | modified | removed
880
881 Returns:
882
883 not_loaded:
884 If Module is not currently loaded.
885
886 loaded:
887 If Module is loaded and the object file exists and contains
888 the same code.
889
890 removed:
891 If Module is loaded but no corresponding object file can be
892 found in the code path.
893
894 modified:
895 If Module is loaded but the object file contains code with a
896 different MD5 checksum.
897
898 Preloaded modules are always reported as loaded, without
899 inspecting the contents on disk. Cover compiled modules will
900 always be reported as modified if an object file exists, or as
901 removed otherwise. Modules whose load path is an empty string
902 (which is the convention for auto-generated code) will only be
903 reported as loaded or not_loaded.
904
905 For modules that have native code loaded (see is_mod‐
906 ule_native/1), the MD5 sum of the native code in the object file
907 is used for the comparison, if it exists; the Beam code in the
908 file is ignored. Reversely, for modules that do not currently
909 have native code loaded, any native code in the file will be
910 ignored.
911
912 See also modified_modules/0.
913
914 modified_modules() -> [module()]
915
916 Returns the list of all currently loaded modules for which mod‐
917 ule_status/1 returns modified. See also all_loaded/0.
918
919 is_module_native(Module) -> true | false | undefined
920
921 Types:
922
923 Module = module()
924
925 Returns:
926
927 true:
928 If Module is the name of a loaded module that has native
929 code loaded
930
931 false:
932 If Module is loaded but does not have native code
933
934 undefined:
935 If Module is not loaded
936
937 get_mode() -> embedded | interactive
938
939 Returns an atom describing the mode of the code server: interac‐
940 tive or embedded.
941
942 This information is useful when an external entity (for example,
943 an IDE) provides additional code for a running node. If the code
944 server is in interactive mode, it only has to add the path to
945 the code. If the code server is in embedded mode, the code must
946 be loaded with load_binary/3.
947
948
949
950Ericsson AB kernel 6.3.1.1 code(3)