v0.52.0 — your shell aliases work in the pit

Your shell aliases work in the pit

An alias that names a shell command used to fail with command not found while the identical word worked when typed at a prompt:

mosh ▸ /prs
  ▸ !gh-prs-all
· zsh -c gh-prs-all
zsh:1: command not found: gh-prs-all

The pit ran everything through $SHELL -c, and zsh -c and bash -c are non-interactive shells — they do not read ~/.zshrc or ~/.bashrc, so the aliases and functions defined there were simply not present. Having ~/.zshrc source your ~/.zsh_aliases made no difference, because the rc file itself was never read.

That was the common case rather than an edge one. Naming a shell command is most of what /alias is for, and the commands people name are the ones they already named once in their rc file.

Shell commands now ask for an interactive shell, so your rc file loads and your aliases and functions resolve. It applies everywhere the pit reaches a shell — !cmd, /shell, a shell-valued /alias, and moshscript's shell() — all through one place, so the line the pit echoes is built from the invocation it actually runs:

mosh ▸ /prs
  ▸ !gh-prs-all
· zsh -ic gh-prs-all

Nothing that worked before stops working: anything already on PATH resolved then and resolves now. What changed is that aliases and functions resolve too.

The scope is deliberately narrow. Only bash and zsh are asked for an interactive shell — fish sources config.fish however it was started, sh and dash have no rc file to miss, and a shell we have not heard of keeps the old behaviour rather than getting a guessed flag. It is also gated on a terminal being attached, because an interactive bash without one prints cannot set terminal process group and no job control in this shell to stderr before running anything, which would wrap every cron, CI, and piped run in noise. Set MOSHCODE_SHELL_NO_RC=1 to buy back a plain -c.

Full changelog: v0.51.0...v0.52.0