You've probably typed export PATH="$PATH:~/.local/bin/" into a dotfile at some point. Most developers have. The problem: those double quotes suppress tilde expansion, so your shell dutifully adds the literal string ~/.local/bin/ to your PATH instead of /home/you/.local/bin/. The result is a relative path — ./~/.local/bin/ — resolved from whatever directory you happen to be standing in. Your intended binaries never get found unless you're in the right place by accident. The mechanism is simple once you see it. Bash and Zsh perform tilde expansion only on unquoted tilde prefixes. The documentation says so explicitly: a word must begin with an unquoted tilde character for expansion to trigger. Inside double quotes, ~ is just a character. The shell also performs tilde expansion in unquoted variable assignments after = and :, which is why export PATH=$PATH:~/.local/bin (no quotes) actually works — but one stray whitespace in that line and the assignment breaks. Fragile by design. The security angle is what makes this more than a curiosity. The nono agent sandboxing tool flagged it: "PATH entries the sandbox can write to: ~/.local/bin/". Because the path resolves relative to the current directory, an attacker who can write to ./~/.local/bin/ in any directory you cd into can inject executables into your PATH. The article demonstrates this directly — mkdir -p ./~/.local/bin/, drop a binary there, and it executes when called by name. No privilege escalation needed, just a misplaced tilde. The fix is one line: replace ~ with $HOME in your dotfiles. $HOME expands inside double quotes because it's a variable, not a tilde prefix. The diagnostic is equally trivial: echo "$PATH" | grep -- '~' will tell you immediately if you have the problem. The author provides a tree output showing the literal ./~ directory structure that gets silently created, which is the kind of concrete proof that makes the gotcha stick. What elevates this from "shell trivia" to "useful technical writing" is the layering: a real tool (nono) surfaced the issue, the bash documentation confirms the behavior, a working exploit demonstrates the consequence, and the fix fits in a tweet. The pedagogical structure — discovery, mechanism, risk, fix, verification — is tight. No wasted motion. The unquoted-assignment escape hatch is worth lingering on. Bash's special-case tilde expansion after = and : in assignments is one of those POSIX accommodations that exists because the common case should work, but it creates a false sense of security. Developers who learn that export PATH=$PATH:~/.local/bin works will reasonably assume the quoted version works too. The quoting rules in shell are already a minefield; this is one more mine. This is a good blog post doing exactly what good blog posts do: taking a specific, reproducible surprise, explaining the mechanism precisely, and leaving the reader with a concrete action item. The writing is clean, the examples are runnable, and the security implication gives it stakes beyond pedantry.
