$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.
$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.
Exactly. It's annoying if I'm just trying to launch an application I installed by typing its name, which is IMO what PATH is for.
How are you installing it? Normally package managers will symlink it into a system defined $PATH directory so you shouldn’t need to faff with $PATH yourself.
Not all applications executable match the application name (eg Visual Studio Code is just “code”). So could that have been the issue?
Depends on the software. Generally, whatever the official installation instructions are.
> So could that have been the issue?
No. Adding things to the path is a reasonably common operation on all OSes and CLI-based software. Sometimes the installer will handle it for you; sometimes it won't. (This may be out of date, but I believe the Rust install script is an example of one that sets it up; Go is one that doesn't, and its official instructions CAO 6 months ago were to use Export, which doesn't work once you reboot)
go install isn’t really an installer. Frankly I don’t really see the point of even having that option.
More broadly speaking, you shouldn’t really be relying on your compiler to do the install. That was never the intended behaviour of a compiler. Which is why history you’d find the install options in the build scripts (eg makefile).
this is why you don't curl | bash