This is just a guess based on the origins of the language, but the design decision probably stems from a dim view of symbolic links. They are seen as ugly hacks that carry persistent state on the filesystem instead of a higher control plane such as a per-process namespace. The path variable approximates this by being settable by an individual shell process, whereas a symlink would affect every process on the system accessing the disk.
On Tuesday, July 12, 2016 at 1:05:36 PM UTC-7, jsej...@gmail.com wrote: > > Don't read this as a complaint. I'm trying to get feedback from code > reviewers about the design decision regarding this behavior of the > installer. > > In my experience, most software for OS X that installs cli components > installs to /usr/local/ and then creates symbolic links to executables in > /usr/local/bin/, as not to modify my $PATH. However, the Go installer > differs in approach by creating a new entry in /etc/paths.d/ for > path_helper > <https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man8/path_helper.8.html> > > to read and then modify my $PATH. Can someone please explain the thinking > behind this design decision? Is it more common on Linux to have a lot of > path additions instead of symbolic links to executables? Was this something > that was discussed and decided upon by the core team or just an arbitrary > decision? > > I'd love to get a better understanding of why this choice. I have never > seen another software take this approach. > > > <https://lh3.googleusercontent.com/-7BiY9UmLB3E/V4VMlKkOlSI/AAAAAAAADbg/NGTdOdAPFA0CGalwQ4q8JNDH91Q3fxOuQCLcB/s1600/go-installer.png> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
