Comment by the__alchemist
9 hours ago
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.
$PATH is not tied to any specific shell. And what you're describing is a shell, so I'm not sure how it's any different from existing solutions.
It is - this is why adding something to the Path is tricky on Linux. Or I should say, there is a mismatch between the common instruction of how to do it (export) vs what you have to do (e.g. edit bash config)
That’s because there isn’t a universal PATH variable.
Env vars are not global. They just have that illusion because a fork() by default will pass your running env vars to the child. Thus trickling that value down.
5 replies →
> Have a universal Path env var that isn't tied to a specific shell
This sounds like Windows. ;)
Environment variables are stored in the registry; for the user, it's
and for system-wide env vars, it's
I always thought that there should be a proc style file system for simlinks to user specific data.
I'm not sure why this can't be done. Security people will have a million reasons, I guess it's possible one of them might be valid.
IIUC, you're describing an extremely restricted (some would say underpowered) shell.
It sounds like you could make it yourself in ~10 lines of Python or bash. I don't see it catching on, though.