Why was --with-default-names removed?

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?

2 Likes

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

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.

$ 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"

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

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.

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

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

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.

To make my scripts work on both linux and mac I installed the commando with brew and then alias the gnu commando.
Example:
brew install grep
alias grep='ggrep'

Now my grep works fine.

I just came across this trying to set up a new system. I agree with the others, this is a painful change. The referenced github issue lists 12 modified packages:
make
grep
gnu-sed
gnu-tar
gnu-time
gnu-which
gnu-indent
gnu-units
inetutils
findutils
ed
coreutils

Of those, there are only 2 or 3 that I don’t routinely use. Having to add 10+ directories to the PATH seems a bit cumbersome. It would be great if there could be some convention (like @richfromm suggested) of putting symlinks into a common directory, so only one directory needs to be added to the path to get the far better GNU versions of these utilities.

Even though, it is tedious, when installing coreutils as a package of multiple bins, then it would be difficult to give a user choice in which tools in the package are prepended and those that aren’t. If it was referenced to a directory, then all of the tools would have to be installed in the directory for $PATH. Only way that I would see this being a user change to not prepend and being prepended with ‘g’ is to have links to certain ones. Which is nothing more than redundancy to adding each tool to $PATH separately and is the original recommendation. For ease of automation, then a script could be used to give the user option to select which tools to add to $PATH post-install.

Please fix this! annoying as heck this was removed

Looking forward to your pull request then. This could also live as an external command in a tap, which I recommend you build first to see how it works and then upstream it to Homebrew/brew.