script(5)

💖 script — Boot script 💖

ok so bestie, this is script, from the Files manual section. It's lowkey the blueprint for how your whole Erlang system wakes up. Let's get into it 🫶

---

✨ NAME ✨

script — the boot script. that's it, that's the vibe. 👑

---

🌸 DESCRIPTION 🌸

The boot script is literally the instruction manual for how the Erlang runtime system gets started. It tells the system which code to load and which processes and applications to start. main character energy, honestly.

The command erl -boot Name starts the system with a boot file called Name.boot, which is generated from the Name.script file, using systools:script2boot/1. no cap.

And where does the .script file come from, you ask? It's generated by systools from a .rel file and from .app files. it's giving family tree 🌈

---

🦋 FILE SYNTAX 🦋

The boot script lives in a file with the extension .script. Here's the syntax, character for character, don't touch it:

{script, {Name, Vsn},
 [
  {progress, loading},
  {preLoaded, [Mod1, Mod2, ...]},
  {path, [Dir1,"$ROOT/Dir",...]}.
  {primLoad, [Mod1, Mod2, ...]},
  ...
  {kernel_load_completed},
  {progress, loaded},
  {kernelProcess, Name, {Mod, Func, Args}},
  ...
  {apply, {Mod, Func, Args}},
  ...
  {progress, started}]}.

ok now let's break each one down, because every single one matters ✨

• Name = string(): — defines the system name. that's the name, bestie.
• Vsn = string(): — defines the system version. iconic.
• {progress, Term}: — sets the "progress" of the initialization program. The init:get_status/0 function returns the current value of the progress, which is {InternalStatus,Term}. so if you ever wanna vibe check where init is at, that's your girl 💅
• {path, [Dir]}: — Dir is a string. This argument sets the load path of the system to [Dir]. The load path used to load modules is obtained from the initial load path, which is given in the script file, together with any path flags that were supplied in the command-line arguments. The command-line arguments modify the path as follows:
  • -pa Dir1 Dir2 ... DirN adds the directories DirN, DirN-1, ..., Dir2, Dir1 to the front of the initial load path. (yes, reversed. it's a whole thing.)
  • -pz Dir1 Dir2 ... DirN adds the directories Dir1, Dir2, ..., DirN to the end of the initial load path.
  • -path Dir1 Dir2 ... DirN defines a set of directories Dir1, Dir2, ..., DirN, which replace the search path given in the script file.

Directory names in the path are interpreted as follows:

• Directory names starting with / are assumed to be absolute path names.
• Directory names not starting with / are assumed to be relative the current working directory.
• The special $ROOT variable can only be used in the script, not as a command-line argument. The given directory is relative the Erlang installation directory. so don't try it on the command line, it won't slay 😭

• {primLoad, [Mod]}: — loads the modules [Mod] from the directories specified in Path. The script interpreter fetches the appropriate module by calling erl_prim_loader:get_file(Mod). A fatal error that terminates the system occurs if the module cannot be located. so like, make sure your modules are actually there, bestie 💀
• {kernel_load_completed}: — indicates that all modules that must be loaded before any processes are started are loaded. In interactive mode, all {primLoad,[Mod]} commands interpreted after this command are ignored, and these modules are loaded on demand. In embedded mode, kernel_load_completed is ignored, and all modules are loaded during system start. two modes, two completely different moods, we love range 🌈
• {kernelProcess, Name, {Mod, Func, Args}}: — starts the "kernel process" Name by evaluating apply(Mod, Func, Args). The start function is to return {ok, Pid} or ignore. The init process monitors the behavior of Pid and terminates the system if Pid dies. Kernel processes are key components of the runtime system. Users do not normally add new kernel processes. so like... hands off, that's the pros' territory 💅
• {apply, {Mod, Func, Args}}.: — the init process evaluates apply(Mod, Func, Args). The system terminates if this results in an error. The boot procedure hangs if this function never returns. so if your function is out here ghosting everyone forever, the whole boot just sits there waiting. not cute 🫠

---

🎀 Note: 🎀

In an interactive system, the code loader provides demand-driven code loading, but in an embedded system the code loader loads all code immediately. The same version of code is used in both cases. The code server calls init:get_argument(mode) to determine if it is to run in demand mode or non-demand driven mode. iykyk ✨

---

👑 SEE ALSO 👑

• systools(3erl)

---

ok that's the whole thing, you ate that 💖 go forth and boot responsibly. this page came to you courtesy of Ericsson AB, from sasl 4.2, and it's the script(5) page, dated the same as always. mwah 💅🎀🦋