CODEWITHSUNDEEP
macosgopathinstallation
jsejcksn
jsejcksn

Reputation: 33693

Go installer behavior on Mac: PATH modification vs symlink

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 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 in an existing directory?

I'd love to get a better understanding of why this choice. I have never seen another software take this approach.

Upvotes: 2

Views: 224

Answers (2)

VonC
VonC

Reputation: 1323223

From this thread, the path_helper (source) is:

because automatic software installation (and what's more important UNinstallation) is much easier this way. Many Linux distros switch to .d directories for many configuration files (Apache 2.0 was AFAIK the first program to support this kind of stuff) because it makes administration much easier.

The Uninstall Go section does mention:

If you installed Go with the Mac OS X package then you should remove the /etc/paths.d/go file.

Those files in /etc/paths.d are processed in order (so you can manage PATH order as opposed to symlinks in /usr/local/bin).

Note that path_helper is only called by login shells, not by non-interactive shells.

Upvotes: 2

aMike
aMike

Reputation: 937

Sorry for using an answer; I don't have enough reputation points to comment. ((which seems backwards to me))

@jsejksn says "I have never seen another software take this approach."

My /etc/paths.d contains entries for Xquartz, CrossPack-AVR, aria2c and go. From reading google'd articles about /etc/paths.d, I see that ImageMagik also adds an entry to /etc/paths.d.

I'd guess that it's an easy way to let users run binaries without having to mess around with amending the PATH in their own profile scripts, or lose track of symlinks, or whatever.

Maybe sym-links is more of a Gnu thing, while /etc/paths.d is more of a BSD thing?

Personally, I like it.

Upvotes: 0

Related Questions