--wrap-process

[passcod]

--wrap-process=group
--wrap-process=session
--wrap-process=pty
--wrap-process=no  or  --wrap-process=false
--wrap-process=pty,group
--wrap-process=session:name
--wrap-process=pty:11

That will provide an alternative to --no-process-group for all the issues that arise from the session -> group change recently.

[unphased]

Could you explain a bit what the practical differences are that we can expect between choosing to wrap with a group or session or pty? Also could you expand a bit on what wrapping even means, since that's not specified in the --help currently.

I have to assume that for the context of running something in response to filesystem events, the purpose of wrapping that something would be to support various ways of more reliably terminating that something. Is that correct?

[passcod]

wrap is a bad term except for all the other terms. there just isn't a good short verb for "attributes set on processes that make them behave differently and also processes can be attached to other processes"

• group is the default and just means in simple terms that there's some expectation that the entire group can be killed or awaited instead of just the 'top of the tree' process
• session imitates what shells do. some programs like erlang don't work well attached to a tty if they're not in sessions, but that's really the only reason for that option.
• pty would behave like if you'd started a separate terminal window but embedded in the watchexec call. if you use tmux or zellij that's the same kind of thing, though watchexec wouldn't do multiplexing as such. you'd use this to better support input or for interactive TUIs. we could also use this for paging i think.
• on linux, cgroup could be another option, it would be like group or session but inescapable, so subchild processes inside the cgroup can be accounted for at all times and can't get out by becoming their own session leader, would be similar to how systemd services work

some of those stack, so a pty implies a session and a session implies a group, but you could specify that you want a pty and a cgroup or something

[unphased]

Quite helpful. That's pretty much exactly the nuance I was looking for.

So I did integrate running watchexec json stdout streaming from within one of my projects I'm working on, in order to gain a bit of control over shutting it down on events... but it was not meant to be:

• I break my app's source code in some way, it breaks the file watching dev loop.
• I still had to implement bash looping and exit code based communication to implement restarting the app and also to not do that if the app really actually wanted to quit.

Basically I learned the hard way that I really do want the file watcher tool to control the dev iteration loop after all.

PTY support will be amazing for enabling quick TUI driving. But having the ability to specify sessions/groups is already powerful and usually sufficient. Seems like for my app which is a web server, just telling it to restart and use SIGINT does the trick. I kinda wanted to use a pty approach because I wanted to do clean shutdowns of my app the way the user might interactively do so, but... it's fine to hook up a signal handler for SIGINT to do the same.

I know this is a tangent but is it possible to easily tell watchexec to watch for all git-tracked files? And possibly specify exceptions from that list. That seems like a nice quick way to get some nearly perfect behavior.