- The `brew uninstall` command has `--zap`, so let's make `brew
reinstall` have parity here for a better user experience. (Requested
in issue 12983.)
- It feels weird that to get my new reinstall test to pass I had to add
`--zap` to `cask/cmd/install.rb`, not `cask/cmd/reinstall.rb` to get
the tests to pass. But the `brew reinstall --cask caffeine --zap`
command worked fine all the time. The CLI argument parser from the
test run was complaining about not knowing what `zap` was. As a
result, `--zap` now shows up as a switch in `brew install --help`
which I'm not 100% convinced is the desired UX. But I've edited the
description accordingly to specify that it will only work on
`reinstall` operations (and `--zap` on `install` is a no-op).
```
issyl0 at pictor in /opt/homebrew on reinstall-cask-zap
❯ brew reinstall --cask caffeine --zap
==> Downloading https://github.com/IntelliScape/caffeine/releases/download/1.1.3/Caffeine.dmg
Already downloaded: /Users/issyl0/Library/Caches/Homebrew/downloads/3d6ccfdd3b8d0ab37d1c2468d6e69078c2d31d3b12bf51947c4db21e5f376af2--Caffeine.dmg
==> Implied `brew uninstall --cask caffeine`
==> Backing App 'Caffeine.app' up to '/opt/homebrew/Caskroom/caffeine/1.1.3/Caffeine.app'
==> Removing App '/Applications/Caffeine.app'
==> Dispatching zap stanza
==> Trashing files:
~/Library/Application Support/com.intelliscapesolutions.caffeine
~/Library/Preferences/com.intelliscapesolutions.caffeine.plist
~/Library/Caches/com.intelliscapesolutions.caffeine
~/Library/HTTPStoages/com.intelliscapesolutions.caffeine.binarycookies
==> Removing all staged versions of Cask 'caffeine'
==> Installing Cask caffeine
==> Moving App 'Caffeine.app' to '/Applications/Caffeine.app'
🍺 caffeine was successfully installed!
```
Add a new method for the two places we're checking if we have any
casks installed. This is much more performance and user friendly than
attempting to load every cask.
Fixes#13027
Add some `--all` flags we'll eventually migrate to to ensure that we'll
eventually require their usage to read all formulae. Where we need to
do stuff later, add some comments.
Allows you to avoid the `Keg::ConflictError` recommending that you invoke `brew link --overwrite` in scenarios when you know that that's how you'd proceed anyway.
Some setups (e.g. a default `tmux` session) will result in a user
starting multiple nested login shells. This is a problem for the way we
currently handle `shellenv` because a login shell invokes
`/usr/libexec/path_helper` which will prepend the contents of
`/etc/paths` and `/etc/paths.d` to `PATH`. In particular, the second
login shell will place `brew` further down the `PATH` than desired in a
non-`/usr/local` prefix, since `brew shellenv` will no longer produce
output the second time around.
Let's fix this by replacing the check that `brew` is in `PATH` with a
check that `${HOMEBREW_PREFIX}/bin` precedes `/usr/bin` in `PATH`.
Fixes#11851, #11883, Homebrew/discussions#2547.
See also:
- Homebrew/discussions#2237
- https://superuser.com/questions/544989/does-tmux-sort-the-path-variable
There's a few bits of functionality that Homebrew has changed over the
years, makes sense as a sensible default but some people find really
annoying:
- automatically running `brew update`
- automatically running `brew cleanup`
- automatically upgrading outdated dependents
- automatically reinstalling broken dependents
For each of these: let's improve the documentation of the commands
whose behaviour is changed and the environment variables themselves.
