Add ability to set the shell

[scottTomaszewski]

What problem are you trying to solve?

In the init_hook I would like to source some scripts containing helper utilities that are written in bash. In devbox run the shell is sh whereas devbox shell the shell is inherited from the caller's shell.

This behavior was confirmed in discord:

We designed it this way initially to make run calls more portable  and consistent. The thinking was that devbox run (especially if used in CI) would use a consistent shell and not be affected by a users specific settings, while devbox shell would use the users shell

which make sense, but if I wanted a consistent shell environment across both devbox shell and devbox run it would be nice to have a way to set that.

More discussion:

• https://discord.com/channels/903306922852245526/1234953700217323541
• https://discord.com/channels/903306922852245526/1251154511746039828

What solution would you like?

Ideally, the solution would be to have support for overriding the default shell for devbox shell and devbox run. For (a contrived) example:

{
  "$schema":  "https://raw.githubusercontent.com/jetify-com/devbox/0.11.0/.schema/devbox.schema.json",
  "packages": ["bash@latest"],
  "shell": {
    "exec": {
      "shell": "/bin/bash --rcfile something.bash",
      "run": "BASH_ENV=something.bash /bin/bash -c"
    },
    "init_hook": [
      "ps -p $$",
      "source .bootstrap.sh"
    ],
    ...

• Splitting out .shell.exec.shell and .shell.exec.run allows for flexibility, but if even without the split my use case is satisfied
• Allowing arguments (not just a shell path) allows for flags to be passed and env vars to be set if necessary
• I understand that this makes for a bit of a mess with inheriting the existing shell. Overriding the shell with this may assume that the --pure flag is automatically set

Alternatives you've considered

• Set the SHELL in the devbox.json env (no effect)
• chsh in the init_hook (requires password or mucking with global filesystem)
• eval bash, bash -l, and other means to starting the desired shell (creates a subshell which doesnt run the devbox run scripts)
• rewriting all our helpers in sh (if I declare bash as a package, I should be able to use it in scripts)
• Prefixing all script lines with bash to force the shell (verbose and problematic with the creation of subshells)

[Lagoja]

I think this is a really good suggestion, and it would help with some shell incompatibility bugs we've seen in the past.

I think I would tweak the proposal to allow the user to specify a shell package they want to install and use as well. For example (not final):

  "shell": {
    "package": "bash@5.1"
    "exec": {
      "shell": "bash --rcfile something.bash",
      "run": "BASH_ENV=something.bash bash -c"
    },

Would install Bash 5.1 from nixpkgs and then run shell/commands/services in that shell. This way you could write zsh/bash/fish specific scripts, and have it work across systems regardless of the user's host shell.