ttyphoon

don't think Murex supports job control (due to processes being marked non-traditionally). You can see higher up in that file above where I need to force Murex to take ownership of the TTY again as part of the process clean up. (line 28 onwards) Processes invoked from a shell should also be part of a process group: https://github.com/lmorg/murex/blob/master/lang/exec_unix.go... You also need to set the shell to be a process session leader: https://github.com/lmorg/murex/blob/master/shell/session/ses... All of this is UNIX (inc Linux) specific so you can see compiler directives at the top of those files to exclude WASM, Windows, and Plan 9 builds. I don't even try to emulate job control on those platforms because it's too much effort to write, test, and maintain. > i have been wondering if it is not possible to get rid of that emulation layer and provide for a more rich way for programs to interact with the user. Funny enough, this is something I'm experimenting with my terminal emulator, though it's very alpha at the moment https://github.com/lmorg/Ttyphoon > to get that emulation layer we only need to port something like tmux onto that new api My terminal emulator does exactly this. It uses tmux control mode so that tmux manages the TTY sessions and the terminal emulator handles the rendering. > https://github.com/yshui/job-security so this can be done without having to reimplement the emulation yet again The problem with a 3rd party tool for job control is that it doesn't work with shell builtins. And the massive value add for shells like Murex and Elvish is their builtins. This is another reason why I didn't want POSIX job control in Murex: I wanted to keep my shell builtins powerful but also allow them to support job control in a way that feels native and transparent to the casual user.