Development record
The guard's script reader treats `pushd` with no operand as going to HOME, but bash swaps the top two directories of the stack instead (zsh does the same unless an option sends it home), so the scripts that follow can be read in the wrong directory. Noticed by guard round 3 on 2026-10-11 while fixing the zsh cd substitution form (iss-2610111809142536); predates it.
issueresolvedminoriss-2610111815024967
The guard's script reader treats pushd with no operand as going to HOME, but bash swaps the top two directories of the stack instead (zsh does the same unless an option sends it home), so the scripts that follow can be read in the wrong directory. Noticed by guard round 3 on 2026-10-11 while fixing the zsh cd substitution form (iss-2610111809142536); predates it.
Frontmatter
| id | iss-2610111815024967 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2610111815024967-guard-reads-bare-pushd-as-home.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2610111809142536zsh reads `cd X Y` with two operands, and an option word it does not take (`cd -e X`, `cd -@ X`, `pushd -n X`), as the substitution form: it replaces the first word in the current directory's path with the second and enters the result, so the guard's script reader judges a script in one directory while zsh runs the one in another. Found by the Fable review of guard round 2 on 2026-10-11 (reproduced with zsh 5.9: `cd <p>/with-n/dir && pushd -n sub && pwd` prints <p>/withsub/dir); the cd forms predate that round, and round 2 made pushd -n read as staying put.