This code starts mymodule:start() of the release. Everything is setup properly by the release.sh created by rebar3. (Credits to the authors of Rebar3!!!). There is a similiar script for Windows release.cmd. But there is no option foreground and using console doesn’t work for me because it starts the shell:
cd %release%
bin\release.cmd console -s mymodule
The release environment is setup well so I thought I could use -eval. But it isn’t possible with console.
Looks like starting a release on Windows is a pain point. I completely understand why most developers are focused on Linux. But unfortunately Windows is the main operating system in most companies .
Currently not being able to start an Erlang program (aka release) is a major blocker to introduce Erlang in my company (100.000+ employees).
I’ll try my best with rebar3 escriptize. My next challenge is to access the priv directory from the embedded archive…
Generally, running an OTP release on Windows is supported just fine. However, the execution model of Windows services is different. E.g., the “foreground” vs. “background” process distinction is a Unix thing. On Windows, service applications are supposed to be controlled by SCM. Therefore, the Windows start scripts generated by Rebar3 are different from the Unix variants: They’re mostly just a frontend to OTP’s erlsrv command, which executes a release as an SCM service. See the usage output (of the extended start script in this case) for the list of supported commands on Windows:
* install - install the release as a Windows service
* start - start the service and Erlang node
* stop - stop the service and Erlang node
* restart - run the stop command and start command
* uninstall - uninstall the service and kill a running node
* ping - check if the node is running
* console - start the Erlang release in a `werl` Windows shell
* attach - connect to a running node and open an interactive console
* remote_console - alias for attach
* list - display a listing of installed Erlang services
* usage - display available commands
That said, you mentioned using -s mymodule as an entry point to your release. This is not the ‘official’ way of starting an OTP release, and it might be more involved to get this working on Windows. The sanctioned way is to (have Rebar3) generate a boot script which tells the application controller how to start your application(s): Typically by invoking foo_app:start/2. Adhering to that convention probably makes things easier, esp. on Windows.
In case that helps, a working example of an OTP application that supports Windows would be eturnal, see the windows subdirectory and maybe the GitHub Action for our Windows-specific build tooling.
The one gotcha we stumbled over is some dependency/race issue that prevents the release from starting up on boot. Our workaround is to tell SCM to delay startup (using a little script called during installation).
If possible, I’d recommend going the “proper release” route rather than messing with escript hacks or similar.
Is there a reason that you would need to do this from a Windows shell instead of using WSL and a “normal” bash shell? WSL is very well integrated into modern Windows.
WSL needs special permissions on company PCs and is not well supported at least at my company. Other problems are knowledge of the end-users with Unix systems, automations / integration into existing environment.
At least in the past WSL had some issues with Windows filesystems, e.g. file permissions. I had some strange effects whose root cause was WSL.
My release is started from command line and ends after the job is done. An application as I understand the concepts starts and runs infinitely. Actually I tried the official way with application:start/2 but exit(-1) produces a dump on the terminal that confuses the end-users. And just returning with a pid keeps the release running.
My current solution is to start with -s mymodule and use application_ensure_all_started/1 and finally stop the release with init:stop(). The main advantage that this procedure supports rebar3, releases and escripts.
But I would appreciate an official solution.
(I still have to browse your eturnal code. There are quite some patterns I can reuse )
BTW, with some hacks the escript solution now works even on Windows.
This is a data processing program that should be integrated into a build chain. Although Jenkins supports Windows and Unix our DevOps team (yes, it’s a separate team…) is not happy with several OSs in the environment, especially for just one job.
Oh, for a command line tool, an escript seems just fine, since the “release” concept is tailored towards long-running services indeed. (I was assuming that you went for an escript just to work around issues with running a proper release on Windows.)
.
)