Why was --with-default-names removed?

(Rich Fromm) #1

I would prefer if the default setup was that installing a tool with brew caused it to “just work” and behave for a user like the same tool on any other GNU system. But even if that’s not the default, at least --with-default-names made it slightly easier to write cross platform scripts between Linux and MacOS.

Why was this removed? It’s breaking assumptions in numerous scripts we’ve written over the years, and overall is making it harder to support multiple dev environments.

So far the only case I’ve heard is that it requires recompilation. Given that the common case is using tools, not installing tools, is that such a big deal?

1 Like
(Sean Molenaar) #2

It also broke a shitton of scripts from people who wrote their scripts from a specific OS if it were the default. As for options In general, users systems have just proven to be a very unreliable build target and therefore homebrew is moving to a binary system where builds are done by CI rather than the users themselves. This means however that anything that wasn’t tested by CI had to be removed.

1 Like
(Rich Fromm) #3

So is there a recommended strategy for writing scripts that will work on both a homebrew-based Mac and an actual GNU system?

To get around the issue in the case that prompted me to discover this, I did the following (in a bash script):

# check GNU coreutils
if which greadlink >/dev/null 2>&1; then
   READLINK="greadlink"
else
   READLINK="readlink"
fi

But that really kind of seems like a pain for every relevant binary for every script. I understand your concerns, but a PATH based approach would be much easier for end users to use IMHO.

(Jonathan Chang) #4
$ brew info coreutils
[snip]
==> Caveats
Commands also provided by macOS have been installed with the prefix "g".
If you need to use these commands with their normal names, you
can add a "gnubin" directory to your PATH from your bashrc like:
  PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"
(Rich Fromm) #5

But the problem with that approach is that a user needs to modify their PATH for every single possibly relevant brew package. (I’m just using coreutils as one example here, there are others.) Is there any way to get a single gnubin dir (even if actually implemented with symlinks), such that a user can add one and only one brew dir to their PATH, and it will just work for any relevant gfoo binaries from any package?

1 Like
(Jonathan Chang) #6

If you want to write a pull request implementing that behavior we’ll review it, but I don’t think this is as big of a problem as you think it might be. Of the 4743 formulae in homebrew/core, 13 install unprefixed binaries into gnubin. It might be possible that you really do need GNU versions of which and ed but this is a pretty uncommon use-case.

(Amknapp) #7

gnu versions of sed, awk and grep that work out of the box are not that uncommon

(Rich Fromm) #8

It’s been a LONG time since I’ve used a non-GNU tar (and I don’t know the details of what ships on a Mac), but in years past that was another commonly used binary for which my recollection is that GNU vs. non-GNU was a significant difference.

Looking at the PR, I see that findutils is also included. find is also commonly used in scripts, although admittedly I don’t know what is different for GNU vs. non-GNU versions.

1 Like
(Rich Fromm) #9

It would be non-trivial for me to write a PR for this, as I don’t even personally have a Mac. (I got pulled into this because I’m writing scripts that run fine on Ubuntu, but then Mac users have trouble with.)

I could borrow one, though, so I’ll think about it. It somewhat depends on how much effort it would take to familiarize myself with the brew codebase, get an environment up and running to be able to test any changes, and learn enough Ruby to feel competent enough to write an acceptable PR. I fear that might be too high a barrier for this, esp. if someone already actively involved could make the changes way faster.