Feature request: use users standard shell (zsh/bash) instead of sh OR make shell configurable

[danbim]

In our development team, we use mprocs as a great lightweight alternative to docker-compose which brings its own set of problems and complexity. So thanks for mprocs, awesome tool! :)

However, we stumbled over the issue that mprocs is executing everything within sh instead of using the current users default shell (e.g. zsh, bash). While this results in reproducibility, it also makes it more complex to set up the environment. To be very concrete, we use direnv to "configure" our development environment. direnv hooks into zsh/bash/fish by having e.g. .zshrc executing an init hook. Because mprocs is using sh, .zshrc, .bashrc and the likes are never executed.

Our wish would be that mprocs would either

a) use the users standard shell (e.g. by evaluating $SHELL, not sure if that's portable enough), or
b) would have the shell configurable within mprocs.json

[pvolok]

Happy to hear that you find mprocs useful.

I wanted to use default shell but quickly gave up on that idea. I think it will bring a lot of confusion if the same mprocs.yaml is used by different users.

Another option is to implement additional fields in config for configuring the shell to use. But I think it would be easier to manually call desired shell:

procs:
  proc1:
    cmd: ["zsh", "-c", "my-command"]

But I'm not sure which arguments to pass to load user's shell rc file.

[isti115]

FYI, pueue just took a very similar route to the configuration you mention.

[damymetzke]

Using the standard shell would be inconsistent, and having an additional field for configuring the shell would be about as verbose as using cmd: ["bash", "-c", "command"]. However such a variable could be ambiguous in my opinion causing more confusion than good. For example:

procs:
  example:
    use_shell: "bash"
    shell: "echo 'Hello World!'"

The difference between use_shell and shell is ambiguous, and I cannot think of a good naming scheme that doesn't result in similar ambiguity.

I do have an alternative suggestion. Add support for 3 more keys: bash, zsh, and fish. Each key would act the same as shell does, but uses the shell corresponding to its name instead of sh. I believe this has a very low chance of causing confusion compared to other ideas.

I can implement this next week and open a PR if the feature is desirable.