The tilde in your PATH may not be your HOME

A short warning that writing export PATH="$PATH:~/.local/bin/" in a shell rc file leaves a literal tilde in PATH because tilde expansion only happens in unquoted words, which can let sandboxed tools write to unexpected directories; it shows how to check for and fix it with $HOME.

I was playing with the nono agent sandboxing tool and it greeted me with a warning: PATH entries the sandbox can write to: ~/.local/bin/ which looked suspicious.

nono warning about PATH entries the sandbox can write to

In other words, doing this in your ~/.bashrc or ~/.zshrc:

export PATH="$PATH:~/.local/bin/"

will not expand the ~ (tilde) into the home path (or $HOME) as the tilde to home expansion happens only in unquoted inputs, as also the bash documentation says:

If a word begins with an unquoted tilde character (‘~’), all of the characters up to the first unquoted slash (…) are considered a tilde-prefix. (…)

Bash checks each variable assignment for unquoted tilde-prefixes immediately following a ‘:’ or the first ‘=’, and performs tilde expansion in these cases. (…)

So instead of having /home/<user>/.local/bin/ added to PATH we end up with ./~/.local/bin/ added to PATH.

And to fix this, we can do this:

export PATH="$PATH:$HOME/.local/bin/"

Note that the unquoted version export PATH=$PATH:~/.local/bin actually works in Bash and Zsh, because tilde expansion is also performed in variable assignments after = and after each :. But relying on that is fragile as for example, a whitespace will break the variable assignment.

The problem can also be seen here:

$ ls -la
total 0
drwxr-xr-x@   2 dc  staff    64 Oct  2 13:37 .
drwxr-x---+ 105 dc  staff  3360 Oct  2 13:37 ..
$ mkdir -p ./~/.local/bin/
$ printf '#include <stdio.h>\nint main() { puts("hello"); }'>a.c; gcc a.c -o ./~/.local/bin/kek
$ PATH="~/.local/bin/" kek
hello
$ tree -f
.
├── ./~
│   └── ./~/.local
│       └── ./~/.local/bin
│           └── ./~/.local/bin/kek
└── ./a.c

4 directories, 2 files

Demo showing that a literal tilde in PATH resolves to a ./~/ directory in the current working directory

As we can see, the kek binary was found and executed from ./~/.local/bin/ — the home directory was never involved.

Check your PATH

You can quickly check whether you have this problem with:

$ echo "$PATH" | grep -- '~'

or, to see each entry on its own line:

$ echo "$PATH" | tr ':' '\n' | grep '~'
~/.local/bin/

If it prints anything, go fix your .bashrc/.zshrc/.profile and replace the ~ with $HOME :).

Btw, kudos to the nono tool for warning about this - even though the warning could be more verbose (PR incoming).