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.
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.
Not all applications executable match the application name (eg Visual Studio Code is just “code”). So could that have been the issue?
> 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)
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).
Distro maintainers test dependencies across all these different pieces of software, but they cannot test against people randomly installing their own versions of software. So it would be negligent for the Go team to advocate overwriting the distro-tested version of Go
Installing arbitrary software, including through the creator's official instructions, is a core capability of a GPOS.
> people randomly installing their own versions of software.
There are 2 things to unpack: Why you are referring to an official release as "randomly installing my own version", and that installing arbitrary software isn't a core component of a GPOS. Further, what does a call-to-only-use-package-managers (Or did I misunderstand you? That's how I'm reading it) has to do with the PATH on linux being terminal-specific?
No, it’s actually not. And when you look at the most popular platforms out there, they do have a primary channel for installing software.
> Why you are referring to an official release as "randomly installing my own version",
It’s not an official release from your OSs package repository. Which is what I actually said.
> and that installing arbitrary software isn't a core component of a GPOS.
I didn’t say that either. I said you’re installing it outside of the package manager so it shouldn’t mess with the platform defaults because it could unknowingly screw up another part of the system that the maintainers are depending on.
If you were to install your own C++ runtime onto Windows and overwrite the Windows default, causing Windows to develop a plethora of bugs. Would you then complain to Microsoft?
This is the equivalent of what you’re doing on Linux and which is why the Go official documentation talks about doing it in a more local scope. Just Google any of the stack exchange and forum discussions around the dangers of updating the system version of Python and Perl. People have done real damage to their systems by overriding the distros shipped version.
No, it’s actually not. And when you look at the most popular platforms out there, they do have a primary channel for installing software.
```
We have very different ideas of what we want out of an OS! I rarely install applications from package managers because the software I use is usually not on them, or is an out of date version. I don't post my own software on them as I'm not going to register and post updates for each OS. I do not think software should be fragmented across incompatible OS app stores.
You’re misrepresenting what I said again.
You argued that installing something outside of a package manager is a core requirement for an OS. And I said it isn’t because what you describe isn’t part of the technical definition of an operating system.
Now you’re arguing that I don’t want to be able to load software outside of package managers, and clearly that isn’t something I said. I’m a massively heavy Linux user and a FOSS maintainer. So I very much do install stuff outside of package managers all the time. But the difference between you and I seems to be that I understand any deviations to the host packages need to be installed elsewhere to avoid conflicts with the OS maintainers versions.
> I don't post my own software on them as I'm not going to register and post updates for each OS. I do not think software should be fragmented across incompatible OS app stores.
I do publish my software to multiple different package managers on different platforms. So I understand the problem well ;)