The Hidden Danger of Using ~ in Your PATH
Don't Put Tilde In Your Path
A common shell configuration mistake: putting ~ in PATH inside double quotes prevents tilde expansion, so ~/.local/bin/ becomes a literal directory relative to the current working directory. This can lead to executing malicious binaries. The fix is to use $HOME instead. Tools like nono now warn about this issue.
Bash checks each variable assignment for unquoted tilde-prefixes immediately following a ‘:’ or the first ‘=’, and performs tilde expansion in these cases.
- SoftTalker
I never use tilde in scripts, only as a convenience when typing commands interactively.
$HOME otherwise, which still has gotchas but they are the same as any other environment variable.
- amarshall
Or you can just…not quote the tilde. Folks always seem to reflexively quote “strings” in Bash while not realizing that (almost) everything is a string and most strings are not quoted and it would be odd to do it (e.g. no one is doing `"ls" "-a" "foo"`).
- thefilmore
You can just do:
PATH=~/.local/bin:$PATH
PATH is already exported. Quotes are also not necessary for assignments.
- FeepingCreature
Kind of seems like you should have noticed this by your ~/.local/bin PATH not working?
- alexpotato
Not necessarily about tildes but about some of the craziness that can happen with bash at large orgs:
At a past job, I was trying to figure out what part of my basrhc was setting a particular environment variable. I assumed that it must be some kind of default installed in my user profile and/or inheriting from /etc/<something>.
I realized pretty quickly that my bashrc was importing some other files. Again, the assumption was that this would be one file deep in the import.
It turned out there were 10+ layers of import starting from an "ur-bashrc" and then layer upon layer of more and more imports to finally get to a user level profile.
It was so convoluted that I was going nuts until I found this Stack Exchange post: https://unix.stackexchange.com/questions/813/how-to-determin...
It turns on "tracing" for bash imports so that you can then narrow down on where the env variable is getting set.
- dspillett
I was going to say “it always seems to work for me” then I saw “… actually works in Bash and Zsh, because …”.
Another Bash-ism I need to be careful not to use when trying to be portable.
It is worth noting that on a lot of systems /bin/sh isn't bash (or zsh) so if you want to rely on Bashisms (or just can't be bothered looking for them) be specific and use “#!/bin/bash” for you hashbang. On Debian and similar it is usually dash for instance.
- the__alchemist
I wish Linux distros would ship a "Terminal"/"CLI" program etc that is decoupled from the scripting language. Have a universal Path env var that isn't tied to a specific shell. Lets you execute cd commands, launch python/git/cargo/arbitrary applications etc, and have a good bookmark + autocomplete system. It feels like the conflation of scripting language + CLI application is the root of these complications and subtleties.
If you are using shell scripting (And prefer Bash etc over Python), you would keep using Bash/Fish/Zsh etc. If you are using the CLI to launch applications that don't have a GUI, navigate directories and perform file system operations, then you would use the plain terminal.
- ligarota
Juste create a file ~ which is a symlink to home :)
Big brain time here