1code(3)                    Erlang Module Definition                    code(3)
2
3
4

NAME

6       code - Erlang code server.
7

DESCRIPTION

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

CODE PATH

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

LOADING OF CODE FROM ARCHIVE FILES

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

CURRENT AND OLD CODE

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

ARGUMENT TYPES AND INVALID ARGUMENTS

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

ERROR REASONS FOR CODE-LOADING FUNCTIONS

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

DATA TYPES

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

EXPORTS

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)
Impressum