What
scripts/install.sh unconditionally appends
# Added by the tracebloc CLI installer
export PATH="<prefix>:$PATH"
to the shell profile on every run, without checking whether an entry for that prefix (or any tracebloc entry) is already there.
Impact
Found on a real machine while validating the v0.10.1 release: ~/.bash_profile had 10 such blocks, every one pointing at a directory that no longer exists (temp prefixes from repeated install tests). For a customer the everyday version is milder but still wrong: each reinstall/upgrade with a non-standard --prefix adds another line, and the profile grows forever. Dead PATH entries are harmless functionally but they're user-visible cruft in a file we don't own, and 10 stale entries in a login profile looks like a broken installer.
Expected
Idempotent: if a tracebloc-managed PATH line for the same prefix already exists, don't add a second one. Ideally also skip the write entirely when the prefix is already on PATH (the common /usr/local/bin case writes a line that changes nothing).
Suggested fix
Before appending, grep the profile for the exact export PATH="<prefix>: string and return early if present; optionally replace any existing tracebloc-managed block for a different prefix rather than appending alongside it. The client installer's equivalent (# Added by tracebloc installer (RFC 0001 #1175)) is the pattern to match — it writes one stable line for ~/.local/bin.
Repro
INSTALL_PREFIX=$(mktemp -d) sh install.sh # run 3x
grep -c 'Added by the tracebloc CLI installer' ~/.bash_profile # -> 3
Found during the 2026-07-29 prod release validation (v0.10.1). Signature/checksum verification and the install itself worked correctly — this is purely the profile write.
What
scripts/install.shunconditionally appendsto the shell profile on every run, without checking whether an entry for that prefix (or any tracebloc entry) is already there.
Impact
Found on a real machine while validating the v0.10.1 release:
~/.bash_profilehad 10 such blocks, every one pointing at a directory that no longer exists (temp prefixes from repeated install tests). For a customer the everyday version is milder but still wrong: each reinstall/upgrade with a non-standard--prefixadds another line, and the profile grows forever. Dead PATH entries are harmless functionally but they're user-visible cruft in a file we don't own, and 10 stale entries in a login profile looks like a broken installer.Expected
Idempotent: if a tracebloc-managed PATH line for the same prefix already exists, don't add a second one. Ideally also skip the write entirely when the prefix is already on
PATH(the common/usr/local/bincase writes a line that changes nothing).Suggested fix
Before appending, grep the profile for the exact
export PATH="<prefix>:string and return early if present; optionally replace any existing tracebloc-managed block for a different prefix rather than appending alongside it. The client installer's equivalent (# Added by tracebloc installer (RFC 0001 #1175)) is the pattern to match — it writes one stable line for~/.local/bin.Repro
Found during the 2026-07-29 prod release validation (v0.10.1). Signature/checksum verification and the install itself worked correctly — this is purely the profile write.