The tilde in your PATH may not be your HOME

Original Article ↗ Hacker News Discussion ↗

Using `~` in shell commands—especially when modifying the `PATH`—can behave very differently than many users expect, because tilde expansion only occurs in specific unquoted positions and varies between POSIX shells and Bash/Zsh extensions. Commenters share pitfalls such as accidentally inserting a literal `~` into `PATH` or even deleting `$HOME`, debate whether user-local directories should precede system paths, and contrast Bash’s many “footguns” with alternative shells like fish, nushell, and zsh. The exchange highlights how subtle quoting and expansion rules, plus inconsistent tooling and documentation, make robust shell usage and scripting harder than it appears.

Tilde expansion and PATH behavior

  • Tilde expands only in specific positions (start of an unquoted “word”; in some shells also after unquoted colons in assignments).
  • Quoting ~ prevents expansion and can leave a literal ~ in PATH, which is the original problem.
  • Some shells (zsh, fish) offer more convenient or array-based ways to add ~/.local/bin to PATH that handle expansion correctly.
  • Several commenters prefer using $HOME instead of ~ in scripts to avoid surprises.

Quoting rules and common shell footguns

  • Misunderstanding when to quote is a major source of bugs: people both over-quote and under-quote.
  • Guidance offered:
    • Always quote variable expansions ("$var") in arguments to avoid word-splitting and globbing.
    • Use single quotes only for literal strings containing special characters.
  • Variable expansion and tilde expansion behave differently; treating them the same leads to errors.

Ordering and security of PATH

  • Debate over whether to prepend or append user directories like ~/.local/bin.
    • One side: append so system binaries take precedence, reducing risk of malicious overrides.
    • Other side: prepend so users can intentionally override outdated system tools.
  • Consensus that if an attacker can write to your PATH directories, you already have a serious compromise.

POSIX vs shell-specific behavior

  • Some behaviors in the article rely on bash/zsh extensions and are not portable to /bin/sh (often dash or ash).
  • POSIX tilde expansion rules were cited; there was initial confusion, then clarification that expansion after unquoted : in assignments is allowed.
  • Several reminders to distinguish “bashisms” from strictly POSIX-compliant constructs.

Alternative shells and language choices

  • Many criticize bash as a “terrible” or fragile scripting language with too many edge cases.
  • Alternatives mentioned: fish, zsh, nushell, murex, PowerShell, Perl, Ruby, etc.
  • Counterpoint: bash/sh remain dominant because they are preinstalled everywhere, especially on remote systems.

Filenames, characters, and robustness

  • Some argue life would be easier if paths only allowed a restricted ASCII set, to avoid encoding and parsing issues.
  • Others strongly defend support for non-Latin scripts and arbitrary Unicode, despite tooling headaches.
  • Using spaces or leading - in filenames is called out as a frequent source of bugs and security pitfalls.

Environment, HOME, and debugging

  • Distinction between $HOME and the account’s home from system databases was noted; these can diverge and confuse ~ resolution.
  • Manipulating HOME for testing can clash with tools that resolve home directories differently.
  • Large organizations often have deeply layered shell startup files, making it hard to track where variables are set; tracing tools for shell startup were recommended.

War stories and lessons

  • Multiple anecdotes: creating a literal ~ directory, accidentally rm -r ~, and AI tools creating ~ directories.
  • Lessons drawn: avoid rm -r when possible, use more explicit paths (./~), and treat shell features with caution.