The installer's shell-configuration step unconditionally appends # Pilot Shell + export PATH=... + alias pilot + alias ccp to every detected shell config file on every install/update, with no way to opt out for users whose shells are managed by a framework or templating system.
Where
installer/installer/steps/shell_config.py — ShellConfigStep:
-
check() always returns False (line 145), so the step always runs.
-
run() (lines 160–186) iterates over each config file and writes the alias block:
alias_existed = alias_exists_in_file(config_file)
if alias_existed:
remove_old_alias(config_file)
...
with open(config_file, "a") as f:
f.write(f"\n{alias_lines}\n")
Even when remove_old_alias strips the matching lines, line 173 immediately re-appends them.
Impact
Users with managed/templated shell configs — where Pilot's PATH/aliases belong in a different file (e.g. a framework env.zsh / aliases.zsh sourced by the user's ~/.zshrc) — see the same four lines re-appended on every install or pilot self-update. They have to keep cleaning them up, which can interact badly with framework startup (in my case, the lines triggered an alias-vs-function parse-time collision).
Repro
- Install pilot-shell.
- Edit
~/.zshrc to remove the appended # Pilot Shell block (or move its contents elsewhere).
- Run
pilot self-update (or re-run the installer).
- The four lines are appended again.
Suggested fixes (any one of these would solve it)
- Sentinel comment: skip a config file if it already contains a marker like
# pilot-shell:managed-elsewhere (caller declares the install is handled by a framework).
- Config flag: honor
~/.pilot/config.json -> installer.skipShellConfig: true.
- Idempotency: skip if a working
pilot is already on PATH and an active pilot alias/function/command resolves correctly — the step has nothing to do.
Happy to send a PR if option 1 or 2 sounds acceptable.
Environment
- pilot-shell installer (current version per
~/.pilot/installer/installer/__init__.py)
- Shell: zsh on Linux
- Framework that owns
~/.zshrc: zshand
The installer's shell-configuration step unconditionally appends
# Pilot Shell+export PATH=...+alias pilot+alias ccpto every detected shell config file on every install/update, with no way to opt out for users whose shells are managed by a framework or templating system.Where
installer/installer/steps/shell_config.py—ShellConfigStep:check()always returnsFalse(line 145), so the step always runs.run()(lines 160–186) iterates over each config file and writes the alias block:Even when
remove_old_aliasstrips the matching lines, line 173 immediately re-appends them.Impact
Users with managed/templated shell configs — where Pilot's PATH/aliases belong in a different file (e.g. a framework
env.zsh/aliases.zshsourced by the user's~/.zshrc) — see the same four lines re-appended on every install orpilot self-update. They have to keep cleaning them up, which can interact badly with framework startup (in my case, the lines triggered analias-vs-functionparse-time collision).Repro
~/.zshrcto remove the appended# Pilot Shellblock (or move its contents elsewhere).pilot self-update(or re-run the installer).Suggested fixes (any one of these would solve it)
# pilot-shell:managed-elsewhere(caller declares the install is handled by a framework).~/.pilot/config.json -> installer.skipShellConfig: true.pilotis already onPATHand an activepilotalias/function/command resolves correctly — the step has nothing to do.Happy to send a PR if option 1 or 2 sounds acceptable.
Environment
~/.pilot/installer/installer/__init__.py)~/.zshrc: zshand