why no /opt/local/libexec/gnubin links for inetutils binaries?

Ryan Schmidt ryandesign at macports.org
Mon Aug 23 20:44:16 UTC 2021

On Aug 18, 2021, at 23:44, Richard L. Hamilton wrote:

> At least ftp and telnet still have their occasional uses, and being without encryption, have been removed on reasonably new macOS versions. So inetutils is useful. But the compulsory "g" prefix is annoying, whereas putting /opt/local/libexec/gnubin at the end of one's PATH so that at least SOME version of telnet, ftp, etc is found, is a simple way to keep scripts working, etc*.

I guess the problem with /opt/local/libexec/gnubin is that several different ports put their symlinks there. If you add that to your PATH, then you're getting all of those binaries in your path, which might not be what you expect.

If you put the gnubin path *after* your system paths (PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/libexec/gnubin) then that's not so bad: if a binary like telnet isn't in the OS, you'll get the one in gnubin.

However the original intention of this directory is to let you override your system binaries with GNU ones if you want that. The coreutils port for example tells the user they can put the gnubin path *before* the other paths (PATH=/opt/local/libexec/gnubin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin). In that case, "cp" would no longer refer to /usr/bin/cp; it would refer to /opt/local/libexec/gnubin/cp. If you have the gsed port installed, "sed" would no longer refer to /usr/bin/sed but to /opt/local/libexec/gnubin/sed. This could break scripts that expect cp and sed to be the macOS versions, but presumably the user electing to do this is aware of that risk.

So I guess there isn't technically a problem. A user wanting cp, sed, telnet, et al to override the system versions can put the gnubin path first, and a user just wanting a fallback in case OS versions don't exist can put the gnubin path last. This distinction would just be something the user should be aware of, and I'm not sure we adequately inform them of this at present. There isn't even consistency at present: coreutils prints notes telling the user about gnubin but gsed doesn't.

A different solution could be for inetutils not to use the g prefix at all, however the port was deliberately changed to use the g prefix years ago so I assume there was a good reason. Maybe some of the other utilities the port installs would shadow system-provided utilities in an undesirable way.

Another fix users could do themselves is to create their own telnet and ftp symlinks in any other directory that is in their PATH.

Another fix could be for the inetutils port to install ftp and telnet both with and without the g prefix on those OS versions that don't include those utilities anymore.

More information about the macports-users mailing list