The Tilde In Your PATH May Not Be Your HOME

TL;DR

Before you orderOffer from Amazon

Get comfort and recovery gear delivered free with Prime

• Fast, free delivery on millions of items
• Prime Video, Amazon Music and more included
• Member-only deals all year

Start your free Prime trial →Free trial for eligible customers · Cancel anytime

As an affiliate, we earn on qualifying purchases.Hide

A report published by Disconnect3d on Oct. 2 says that quoting a PATH assignment such as `export PATH=”$PATH:~/.local/bin/”` can leave the tilde literal instead of expanding it to the home directory. The suggested fix is to use `$HOME`, and the report offers commands to find PATH entries that still contain `~`.

A report published by Disconnect3d on Oct. 2 warns that a commonly used shell configuration, `export PATH=”$PATH:~/.local/bin/”`, may add a literal `~/.local/bin/` entry rather than the directory under a user’s home folder. The report recommends using `$HOME/.local/bin/` instead, a distinction that can affect which executable a shell finds and may matter to tools that inspect writable PATH locations.

Disconnect3d said the issue came to attention while using the nono agent sandboxing tool, which displayed a warning about PATH entries the sandbox could write to. The report author found the displayed `~/.local/bin/` suspicious and traced it to how shells handle tilde expansion. In the quoted assignment, the tilde is inside double quotes, so it is not expanded as a home-directory prefix.

As a result, a shell can treat the entry as the relative path `./~/.local/bin/`, rather than a path such as `/home//.local/bin/`. Disconnect3d illustrated the behavior by creating a directory named `~` in the current working directory, placing a test executable there, and running it with that literal path in `PATH`. The executable ran, showing that the home directory was not involved in that example.

The suggested replacement is `export PATH=”$PATH:$HOME/.local/bin/”`. The report also notes that an unquoted assignment such as `export PATH=$PATH:~/.local/bin` can expand successfully in Bash and Zsh. However, the author describes relying on that behavior as fragile, since whitespace can alter how the shell parses an assignment.

How a PATH Entry Can Mislead

The issue matters because PATH controls where a shell looks for commands. If a startup file adds a literal tilde path, a command might be found in a directory relative to the current working directory instead of in the user’s home directory. Disconnect3d’s example shows that a program placed in such a relative directory can be executed when its name is entered, provided the directory is in PATH.

The report also connects the mistake to security checks on writable PATH locations. A sandbox warning about writable entries may be harder to interpret if a user assumes `~/.local/bin/` necessarily means a home-directory location. The report establishes the shell-expansion behavior and demonstrates a test case; it does not claim that every quoted tilde entry creates a security incident or that the nono warning itself proves an exploit.

The Shell Expansion Rule

In its discussion, Disconnect3d points to the Bash documentation, which says tilde expansion applies when a word begins with an unquoted tilde prefix. Bash also checks certain variable assignments for unquoted tilde prefixes immediately after a colon or the first equals sign. This explains why an unquoted tilde after a colon can behave differently from the same character inside double quotes.

The difference is between the literal character `~` and the home-directory value; a PATH string is not automatically rewritten just because it contains a tilde. The blog post discusses Bash and Zsh and recommends `$HOME` as the less fragile form. It does not provide a comparison of behavior across every shell or operating system.

““export PATH=”$PATH:$HOME/.local/bin/”””

— Disconnect3d, describing the recommended fix

Limits of the Reported Example

The report does not say how many people have affected shell configuration files, how often this mistake occurs, or whether the behavior causes problems in a particular user’s setup. Its demonstration is a reproducible example, not evidence of a widespread incident. The author also does not document testing across shells beyond the stated Bash and Zsh behavior.

Disconnect3d said a pull request was forthcoming to make nono’s warning more verbose. The source does not confirm whether that change was submitted, accepted, or released. It also does not report any compromise or other security impact tied to the warning.

Check Startup Files and Tool Changes

Readers can inspect their current PATH with the commands in the report: `echo “$PATH” | grep — ‘~’` searches the full value, while `echo “$PATH” | tr ‘:’ ‘\n’ | grep ‘~’` prints matching entries separately. A result means the PATH string contains a tilde; users should check their shell configuration to determine whether that entry is intentional and how it was assigned.

Disconnect3d recommends checking `.bashrc`, `.zshrc` and `.profile` and replacing an affected tilde with `$HOME`. The next reported development is the proposed nono warning improvement; the original post does not provide a timeline or confirm its status.

Key Questions

What is the PATH tilde problem?

A quoted assignment such as `export PATH=”$PATH:~/.local/bin/”` can preserve `~` literally instead of expanding it to the user’s home directory. The entry may then refer to `./~/.local/bin/` relative to the current directory.

What should I use instead?

Disconnect3d recommends `$HOME/.local/bin/`, for example: `export PATH=”$PATH:$HOME/.local/bin/”`.

How can I check whether PATH contains a tilde?

Run `echo “$PATH” | tr ‘:’ ‘\n’ | grep ‘~’` to print PATH entries containing `~`. Then check the relevant shell startup file to see how each entry is defined.

Does finding a tilde in PATH prove my system was compromised?

No. The report describes a shell configuration behavior and a test demonstration, not evidence of a compromise. A matching entry is a reason to inspect the configuration and understand what directory it refers to.

Source: hn