The behavior of some programs (e.g., emacs) differs depending on
whether INFOPATH is terminated in a colon or not. For example, the
info viewer built into emacs has a default list of places from which
it will draw info files, and it will only check this if either (a)
INFOPATH is unset, or (b) INFOPATH ends in a colon.
Currently brew shellenv prepends to the existing $INFOPATH and will
separate with a colon if $INFOPATH already exists, but if it does not
it will not terminate in a colon. As a result, info
pages (like emacs and elisp) are missing from the info viewer.
The existing brew shellenv logic used a parameter expansion trick to
include a colon only if it was prepending to an extant INFOPATH, but
because we want brew's contribution to the INFOPATH to always end in a
colon (whether there's an existing INFOPATH or not), we don't have to
use the parameter expansion trick
This commit only changes behavior for "other" shells (i.e., not fish,
csh, or tcsh) since I don't know how to append a colon to variables in
these shells.
This ensures that dependencies are verified and tapped before they are
fetched. `FormulaInstaller#lock` has been moved into
`FormulaInstaller#install` to avoid locking until necessary.
While we're here, don't compute dependencies before fetching if we're
not going to use them.
In #7526 a comparison for `paths` was introduced, but if `paths` is ever
`nil`, this triggers an error.
Coercing the variable to an Array should alleviate this problem, as
`nil.to_a` produces an empty and comparable Array.
Fixes#7540
Signed-off-by: Mike Fiedler <miketheman@gmail.com>
We don't remove `etc` files on uninstall. Now we have `pkgetc`, though,
we have a pretty decent guess at what files in `etc` may belong to a
given package and can warn about them being left around on uninstall.
Thoughts: should we do the same thing for `var`? I don't see it being
used nearly as consistently.
I interpreted the existing message as meaning "you don't pin
a tap any more, rather you pin a specific formula from that
tap". I.e. the command still worked, but it had to be done
on a per-formula basis (eg. `brew tap-pin linuxbrew/xorg/mesa` instead
of just `brew tap-pin linuxbrew/xorg`)
IMO, this makes it clearer that the command itself is no longer
supported.
Refactor the CLI::Args module so it doesn't have different paths to
check arguments depending on whether the arguments have been parsed or
not. Instead, set the values we need from the global ARGV at
first, global initialisation time where they will be thrown away when
the actual arguments are parsed.
To do this some other general refactoring was needed:
- more methods made private when possible
- e.g. `HEAD?` used consistently instead of `head` before arguments
are parsed.
- formula options are only parsed after named arguments are extracted
As-of https://github.com/Homebrew/homebrew-portable-ruby/pull/100 we've
removed ARM builds for Portable Ruby due to months of breakage.
Similarly, when we last bumped Portable Ruby the ARM build was much
delayed but, despite Homebrew/brew being completely unusable to anyone
using it on ARM in that case, no-one complained or filed issues.
Instead of attempting to maintain and update a Portable Ruby on niche
(Homebrew) platforms like ARM (or, in past/future PPC) improve the
messaging to provide users with a workaround.
Now we allow only a major/minor version match it should be pretty
doable for those users to install e.g. a prebuilt Ruby binary from a PPA
or built it from source if needed using `ruby-build` and `rbenv`.
The messaging could be improved further but we're somewhat limited by
`ruby.sh` and `vendor-install.sh` being separate. I'm tempted to combine
them (or at least have `vendor-install.sh` not be so generic as to not
be able to give Ruby-specific advice).
$SHELL is set to only the binary name in some environments (e.g. fish, not /usr/bin/fish), causing detection of fish/csh/tsch to fail without this change.
