fix(install): pin bash-preexec to 0.6.0 release

[ChrisJr404]

What

install.sh and the bash install docs fetch bash-preexec.sh from master instead of a release tag. This PR pins all three call sites to the 0.6.0 tag.

Why

A commit landed on master after the 0.6.0 release that adds a PS0 based preexec hook for bash 5.3+ using the new "command substitution that has no value" syntax:

PS0=${PS0-}'${ __bp_invoke_preexec_from_ps0 "$_" >&2; }'

Ubuntu 26.04 ships bash 5.3.9, which activates that branch. Under some shell environments the funsub body is printed verbatim before each command instead of being suppressed cleanly, producing the __bp_invoke_preexec_from_ps0 "..." >&2; } text the issue reports.

I can reproduce the literal leak locally with bash 5.3.9 by sourcing the master file with promptvars off:

$ echo HELLO
${ __bp_invoke_preexec_from_ps0 "$_" >&2; }HELLO

The reporters in #3456 have promptvars on, so something else in their ~/.bashrc flips the funsub from "fires silently" to "prints body", and I haven't pinned down the exact environmental trigger from the issue alone. What's clear is that 0.6.0 doesn't set PS0 at all, so pinning to that tag sidesteps the whole code path regardless of which environment trigger is at play.

I'm not 100% sure this matches every report in the thread (one user noted ble.sh fixed the history symptom but not the gibberish), but the gibberish signature is unambiguously the PS0 hook from master, and pinning a release tag is the right move either way for a fetched dependency.

History capture

0.6.0 still installs the DEBUG-trap preexec path, which fires __atuin_preexec on every command, so atuin history capture continues to work on bash 5.3.9.

Files changed

• install.sh line 65 (the actual install path users hit)
• docs/docs/guide/installation.md (English docs bash-preexec manual setup instructions)
• docs-i18n/zh-CN/README.md (Simplified Chinese mirror of the same)

Long term

The underlying bug belongs upstream in bash-preexec. Pinning here protects new atuin installs in the meantime; a future bump to a new bash-preexec release that fixes the PS0 funsub is a small follow-up.

Refs #3456

[greptile-apps]

Greptile Summary

Pins bash-preexec.sh to the 0.6.0 release tag at all three fetch sites, replacing the previous master references that picked up a post-release PS0 hook causing visible garbage output on bash 5.3+.

• install.sh: the live install path users actually run
• docs/docs/guide/installation.md and docs-i18n/zh-CN/README.md: manual setup instructions updated to match

Confidence Score: 5/5

Safe to merge — three one-line URL substitutions with no logic changes.

The change is three identical string replacements swapping master for a pinned tag. 0.6.0 still ships the DEBUG-trap preexec path atuin relies on, so no functionality is lost. Risk is low.

No files require special attention.

Important Files Changed

Filename	Overview
install.sh	Pins bash-preexec fetch from master to the 0.6.0 tag, preventing the PS0 hook regression on bash 5.3+
docs/docs/guide/installation.md	Same master → 0.6.0 pin in the English manual setup instructions
docs-i18n/zh-CN/README.md	Same master → 0.6.0 pin in the Simplified Chinese docs

_{Reviews (1): Last reviewed commit: "fix(install): pin bash-preexec to 0.6.0 ..." | Re-trigger Greptile}

[akinomyoga]

This was also reported at rcaloras/bash-preexec#186.

The reporters in #3456 have promptvars on, so something else in their ~/.bashrc flips the funsub from "fires silently" to "prints body", and I haven't pinned down the exact environmental trigger from the issue alone.

The problem is caused by /etc/profile.d/vte.sh, which leaves an unclosed backslash escape as PS0='<something>\'. Then, when any other frameworks append any expansions such as PS0+='$var', the beginning $ is escaped and the entire expansion is suppressed.

I'm not 100% sure this matches every report in the thread (one user noted ble.sh fixed the history symptom but not the gibberish), but the gibberish signature is unambiguously the PS0 hook from master,

The user should have loaded both ble.sh and bash-preexec in Bash sessions, because ble.sh doesn't include any strings like ${ __bp_invoke_preexec_from_ps0 "..." >&2; }. It should be noted that, even if the user doesn't explicitly load bash-preexec.sh, a certain version of bash-preexec may be included in other scripts, such as the terminal's shell integration scripts (by iTerm2, kitty, Ghostty, VS Code Terminal, etc.), injected on the startup of Bash, or by a framework such as Bash-it.

[akinomyoga]

Ah, sorry. I intended to reply to the original issue #3456 (instead of this PR #3469). I'll also reply to the original issue.

[akinomyoga]

We've submitted a patch to the upstream: https://gitlab.gnome.org/GNOME/vte/-/work_items/2951.