start_erl(1)

πŸŽ€ start_erl πŸ’…

okay so bestie, welcome to the Erlang Module Definition manual page for start_erl β€” erts 17.0.6 era, we're being vintage and iconic about it ✨


🌸 NAME 🌸

start_erl β€” start Erlang for embedded systems on Windows systems πŸͺŸ

πŸ¦‹ DESCRIPTION πŸ¦‹

start_erl is specific to Windows NT/2000/XP (and later versions of Windows, so basically every Windows you'll ever touch πŸ’–). And listen β€” there are programs with the same name on other platforms, but their functionality is different. do not get it twisted, they are not the same girl πŸ‘‘

It's distributed in two forms: compiled (living under <Erlang root>\erts-<version>\bin) and as source (under <Erlang root>\erts-<version>\src 🧚). Why do you get the source? So you can customize it for your local needs, like cyclic restart detection πŸŒ€. There's also a "make"-file, written for the nmake program distributed with Microsoft Visual C++. That said, the program can be compiled with any Win32 C compiler (possibly with minor modifications β€” no judgment, just facts πŸ’…).

So what does it do? It aids release handling on Windows systems ✨. The program is to be called by the erlsrv program, reads up the release data file start_erl.data, and starts Erlang. And the tea is: some options to start_erl are added and removed by the release handler during upgrade with emulator restart (more specifically, option -data). iykyk πŸ‘€

Here's the vibe, formally:

start_erl [<erl options>] ++ [<start_erl options>]

The start_erl program in its original form recognizes the following options:

  • ++ β€” Mandatory, bestie, not optional, can't skip it 🚧. It delimits start_erl options from normal Erlang options. Everything on the command line before ++ is interpreted as options to be sent to the erl program. Everything after ++ is interpreted as options to start_erl itself. periodt.
  • -reldir <release root> β€” Mandatory if the environment variable RELDIR is not specified and no -rootdir option is specified. It tells start_erl where the root of the release tree is located in the file system (typically <Erlang root>\releases). The start_erl.data file is expected to be located in this directory (unless otherwise specified, ofc). And if only option -rootdir is specified, the directory is assumed to be <Erlang root>\releases πŸ“.
  • -rootdir <Erlang root directory> β€” Mandatory if -reldir is not specified and no RELDIR exists in the environment. This specifies the Erlang installation root directory β€” the one under which the lib, releases, and erts-<Version> directories are located. But if only -reldir (or the environment variable RELDIR) is specified, then the Erlang root is assumed to be the directory exactly one level above the release directory. exactly one. no rounding. πŸ‘†
  • -data <data file name> β€” Optional. Specifies another data file than start_erl.data in the <release root>. You specify it relative to the <release root>, or absolute (including drive letter, and so on). Now the warning 🚨: this option is used by the release handler during upgrade and is not to be used during normal operation. Also, normally the release data file is not to be named differently. so like... hands off πŸ’€
  • -bootflags <boot flags file name> β€” Optional. Specifies a file name relative to the release directory (that is, the subdirectory of <release root> where the .boot file and others are located). The contents of this file is appended to the command line when Erlang is started. Which is so cute actually β€” it makes it easy to start the emulator with different options for different releases ✨

πŸ“ Notes πŸ“

  • As the source code is distributed, it can easily be modified to accept other options. BUT β€” the program must still accept option -data with the semantics described above for the release handler to work correctly. non-negotiable, she's load-bearing 😀
  • The Erlang emulator is found by examining the registry keys for the emulator version specified in the release data file. So the new emulator must be properly installed before the upgrade for this to work. install first, upgrade second, that's the order πŸ”‘
  • Although the program is located together with files specific to the emulator version, it is not expected to be specific to the emulator version. Also important: the release handler does not change option -machine to erlsrv during emulator restart. So locate the (possibly customized) start_erl program somewhere it won't be overwritten during upgrade. protect her 🫢
  • The default options of the erlsrv program are not sufficient for release handling. The machine started by erlsrv is to be specified as the start_erl program, and the arguments are to contain ++ followed by the desired options. forget the ++ and it's giving chaos πŸ’€

πŸ‘€ See Also πŸ‘€

erlsrv, release_handler


and that's the whole page, bestie β€” brought to you by Ericsson AB, erts 17.0.6, no cap πŸ’œ stay slaying those embedded Windows releases πŸŒˆπŸŽ€

πŸ“¦ where this page comes from