There are many programming languages that don't by default produce native executables. Among them are Python, Java, Ruby, Perl, Raku, ... The list goes on. When creating an application in any of those languages one will at one point typically hit the issue that the application can only be started by calling a the language interpreter and passing a few arguments. The usual solution is to write a small wrapper shell script on *nix and a bat file on Windows. That's a quick solution. But getting such wrapper scripts really right is not trivial. Typical pitfalls are:
- making the script independent of the current working directory
- having it working in all *nix environments (i.e. make it work in POSIX shell instead of say bash)
- On Windows passing command line arguments on (it's actually impossible to do correctly in batch files)
- On Windows not losing the connection to the terminal (there is no
execon Windows)
A few years ago I started working on a tool to help generating robust wrappers for this use case. I've finally pushed it over the finish line.
Executable Runner Generator
So here it is, the Executable Runner Generator. The name could have been chosen better, but I guess we'll have to live with it now. It's written in the Raku language, but the generated wrappers are independent of the language. Currently it can generate wrappers that work on Windows x86_64 and all sorts of POSIX systems.
In general the task of the wrapper is to put together a command line (and runtime environment like CWD and env vars) and execute the program. How exactly that happens is configured via a set of options. The wrapper has the ability to:
- Convert paths to absolute or relative to the wrappers file system location
- Change path separators on Windows
- Change the current working directory
- Specify the command line arguments to pass to the program
- Forward the arguments passed to the wrapper
- Add and remove environment variables
A webservice
As not everyone is keen to install Raku on their system just to generate a wrapper, I've set up a small website that exposes the functionality as a website:
Call for help
On Windows the generator relies on a native executable written in C to do it's magic. There is no exec syscall on Windows. The program works around this by staying alive, letting the child process inherit it's file descriptors and once the child finishes, returns with it's exit code. I'm pretty sure this "exec emulation" isn't perfect. But as I'm not a Windows low level expert I don't even know what I'm missing. Signals? Security contexts? I don't know.
So: If you are knowledgeable of the lower Windows APIs, I'd love to get feedback on the implementation or maybe even a patch.
Top comments (0)