[zsh] [mac] On Mac OS puma-dev loads interactive zsh init files
alfuken opened this issue · comments
On Mac OS puma-dev loads interactive zsh init files.
Which it should not do.
According to https://zsh.sourceforge.io/Intro/intro_3.html:
`.zshenv' is sourced on all invocations of the shell, unless the -f option is set. It should contain commands to set the command search path, plus other important environment variables. `.zshenv' should not contain commands that produce output or assume the shell is attached to a tty.
`.zshrc' is sourced in interactive shells. It should contain commands to set up aliases, functions, options, key bindings, etc.
`.zlogin' is sourced in login shells. It should contain commands that should be executed only in login shells.
I have a "read" prompt in my .zshrc that dies if no valid input provided. Which leads to
! Booting app 'a-1ba316d3' on socket /Users/alfuken/.puma-dev/projname/tmp/puma-dev-1521.sock
a-1ba316d3[6770]: not interactive and can't open terminal
a-1ba316d3[6770]: /Users/alfuken/.zshrc:4: unknown file attribute: 1
a-1ba316d3[6770]: bash: line 27: exec: puma: not found
! Killing 'a-1ba316d3' (6770) - 'stdout/stderr closed'
* App 'a-1ba316d3' shutdown and cleaned up
! Detecting app 'a-1ba316d3' dying on start
and... did it really just wrote "bash" there? It tries to execute bash from under the zsh shell? Uhh...
Something looks really messed up...
This is related to #295 and doesn't have a clear resolution, yet. But, it's a good point, so here's my current thinking.
Currently, puma-dev uses SHELL to determine which top-level shell to execute. That shell is invoked with -l, presumably because it provides a zeroconf way to get access to a groomed ruby environment. Then, as you rightly pointed out, it executes puma under bash to source all of the puma-dev configuration files.
Supporting a custom, configurable SHELL would solve #295, even in launchctl. Perhaps, in doing so, we should also allow you to customize the opts passed to that shell, which would then allow you to omit the -l flag currently being passed to zsh.
Bash will likely continue to be the (default? only?) execution shell used to invoke puma, but that could also be driven by configuration.
How about allowing the user to customise the executionShell? Say, pre-install it as ~/.puma-dev/executionShell (or ~/.puma-dev/config/executionShell or ~/.puma-dev-rc or anything like that) and load it from there instead of having hardcoded.
That way you could point launchctl to that file and it should take care of deciding on which shell should it use, be it bash, zsh, or any other shell (IIRC, it respects shebang).
To deal with updating and versioning, an executionShellVersion variable could be added to that file, so on new version release puma-dev executable could compare those two versions, and, in case there's an update to the default, warn user in some way. For example, similar to current error pages, by rendering plain-text page saying "there's a new version of the executionShell, check this link to see the changes".