The Tilde In Your PATH May Not Be Your HOME

TL;DR

Before you orderOffer from Amazon

Get the latest gadgets 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 developer Disconnect3d warns that writing a quoted `~` path into PATH can leave the tilde unexpanded, so a command may be found in a literal `./~` directory rather than the user’s home directory. The report recommends using `$HOME` and provides a command for checking PATH entries; the issue depends on how the shell assignment is written.

Developer Disconnect3d reported October 2 that a common-looking shell configuration, export PATH="$PATH:~/.local/bin/", may add a literal tilde path rather than the user’s home directory to PATH. The issue came to the developer’s attention when the nono agent sandboxing tool warned that it could write to ~/.local/bin/, and it matters because shell commands may be found in an unexpected directory.

In the report, Disconnect3d says the tilde is not expanded in the quoted value in that example. Instead of adding a location such as /home/<user>/.local/bin/, the assignment can leave ~/.local/bin/ as a literal PATH entry. When a shell searches a relative PATH entry, that can correspond to a directory named ~ beneath the current working directory—not the user’s home directory.

The author recommends using the explicit environment variable $HOME: export PATH="$PATH:$HOME/.local/bin/". Disconnect3d also demonstrates the distinction with a test: a program placed in ./~/.local/bin/ was found and run when PATH was set to ~/.local/bin/. That example shows the literal-directory behavior; it does not establish that every machine or configuration will have such a directory or execute a program from it.

The report notes that an unquoted assignment, such as export PATH=$PATH:~/.local/bin, does expand the tilde in Bash and Zsh under the described conditions. The author cautions that relying on this is fragile, because whitespace can alter how the shell parses an assignment. The report points to Bash’s documented tilde-expansion rules, which include unquoted tilde prefixes at particular positions in assignments.

How a Literal Path Can Mislead

PATH determines which directories a shell searches when a user enters a command. If a configuration intended to add a home-directory folder instead adds a literal or relative ~ directory, the command may not be found where the user expects. If a matching executable is present in that relative directory, it may be run instead, as Disconnect3d’s test illustrates.

That difference can affect troubleshooting and, depending on the files and working directory involved, which executable is selected. The report does not claim a confirmed compromise or show that a real system was harmed. Its practical point is narrower: use an unambiguous home path and inspect PATH when a configured command behaves unexpectedly.

The Shell Rules Behind the Tilde

The report was prompted by a warning from nono, described by Disconnect3d as an agent sandboxing tool. The warning identified ~/.local/bin/ among PATH entries the sandbox could write to. Disconnect3d investigated why that entry looked suspicious and traced the concern to the difference between a tilde written in an unquoted shell word and one inside the quoted value shown in the example.

Shell tilde expansion is governed by syntax, not simply by the presence of a tilde in a string. The report cites Bash documentation describing expansion for an unquoted tilde prefix and certain positions in variable assignments. It also says the unquoted form works in Bash and Zsh for the example, while recommending $HOME as a clearer option. The source does not compare behavior across other shells or discuss every possible PATH assignment.

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

— Disconnect3d, on the recommended fix

How Broad the Issue Is

The report documents a specific assignment pattern and a local demonstration, but does not provide data on how often it appears in shell configuration files or how many users are affected. It also does not test every shell, operating system, or configuration-loading path. The precise behavior can depend on shell parsing and how PATH is set.

Disconnect3d says a pull request to improve the nono warning was forthcoming. The report does not say whether that change was submitted or accepted. It also does not describe a security incident; the demonstrated concern is that a literal relative path can lead command lookup to a different location than intended.

Check and Correct PATH Entries

Disconnect3d suggests checking for tilde characters in the current PATH with echo "$PATH" | grep -- '~'. To inspect entries separately, the report gives echo "$PATH" | tr ':' '\n' | grep '~'. If the output shows a suspect entry, the author recommends reviewing shell startup files such as .bashrc, .zshrc, or .profile and replacing the tilde with $HOME where appropriate.

The next developments mentioned in the source are the proposed improvement to nono’s warning and any changes users make after checking their configurations. No release date or tool update is specified. For readers, the immediate step is to verify what PATH actually contains rather than assuming a tilde was expanded.

Key Questions

Does a tilde in PATH always fail to expand?

No. Expansion depends on shell syntax. The report says the quoted example can leave the tilde literal, while an unquoted assignment in Bash and Zsh works under the conditions described.

What should I use instead of a quoted tilde?

Disconnect3d recommends $HOME, as in export PATH="$PATH:$HOME/.local/bin/", to name the home-directory path explicitly.

How can I check whether my PATH contains a tilde?

Run echo "$PATH" | tr ':' '\n' | grep '~' to print entries containing a tilde. The report says any output is a reason to review the relevant shell configuration.

Does the report describe a security breach?

No breach is reported. The author demonstrates that a command can be executed from a literal ./~/.local/bin/ directory when PATH is set that way, but does not claim a real-world compromise or quantify the risk.

Source: hn