I considered doing a fallthough in the case-statement, but that doesn't work on bash leq 4 (notably, those versions shipped with MacOS by default).
I chose to prepend the value to the array to mirror the homebrew completion [instructions page](https://docs.brew.sh/Shell-Completion).
I also chose to leave off the `-d`irectory check -- zsh seems to tolerate invalid paths, so there isn't much harm in adding it anyway.
I'm flexible on any of these choices should someone feel strongly. However, I imagine this is the best combination given the trade-offs we have.
Some programs like `vapigen` might not work correctly, when `XDG_DATA_DIRS`
does not include `$HOMEBREW_PREFIX/share`. Instead of requiring the user
to manually adjust the shell environment, we can set `XDG_DATA_DIRS` as
part of `cmd/shellenv`, so that it is sufficient to run `brew shellenv`
on any particular system.
Fixes#18317
On macOS 14 and newer, `/usr/libexec/path_helper` supports setting a
`PATH_HELPER_ROOT` environment variable.
With this set, `path_helper` checks `$PATH_HELPER_ROOT/etc/paths` and
`$PATH_HELPER_ROOT/etc/paths.d` in the same way it checks `/etc/paths`
and `/etc/paths.d`.
We can use this to simplify management of the user's `PATH` variable
when they do `brew shellenv`. In particular, if their system supports
it, we delegate setting the `PATH` environment variable to `path_helper`
instead of our own code. We also write a default `etc/paths` file if one
is not already present.
This is nicer because it simplifies management of the user's `PATH`
variable. For example, if a user wants a keg-only formula to be in their
`PATH`, they can simply add the necessary path to `/etc/paths` or
`/etc/paths.d` without having to do something like `brew link --force`
or adding to `PATH` themselves.
When `/usr/libexec/path_helper` is not available, we just fall back to
the existing code.
Fish didn't support `$(...)` substitution until v3.4.0, but the command
didn't work with just parenthesis, so rewrite the test to prepend an
empty string if MANPATH is non-empty (to trigger a leading colon).
Only manipulate INFOPATH in Fish if Homebrew not in path already.
The current appended colon means system man pages always shadow
Homebrew's. There's also no point adding Homebrew's man dir, nor
filling out an empty MANPATH, since `man` and friends will add the
necessary dirs according to PATH.
Closes https://github.com/Homebrew/homebrew-core/issues/176037.
Also fixed a syntax error in the `*csh` INFOPATH setting.
fish's `set` doesn't modify the exit status when assigning a variable.
This means that `set -q VAR; or set VAR ...` will return an exit status
of 1 even if the variable is suceessfully set. By switching the commands
to `! set -q VAR; and set VAR ...`, this prevents the 1 from propogating
when running `eval (brew shellenv)`.
These were introduced by typos and an incorrect assumption on the last
update of #15358. The last commit had been tested with a parameter, but
had not been re-tested *without* parameter.
Apologies for the error.
Resolves#15358
With this change, `brew shellenv` will accept a shell name parameter to
override its default output (based on `/bin/ps`) for advanced use cases
such as with dotfile templating and caching with
[twpayne/chezmoi](https://github.com/twpayne/chezmoi/discussions/2971).
When running under `fish`, this is the output:
```console
$ brew shellenv pwsh
[System.Environment]::SetEnvironmentVariable('HOMEBREW_PREFIX','/opt/homebrew',[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('HOMEBREW_CELLAR','/opt/homebrew/Cellar',[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('HOMEBREW_REPOSITORY','/opt/homebrew',[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('PATH',$('/opt/homebrew/bin:/opt/homebrew/sbin:'+$ENV:PATH),[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('MANPATH',$('/opt/homebrew/share/man'+$(if(${ENV:MANPATH}){':'+${ENV:MANPATH}})+':'),[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('INFOPATH',$('/opt/homebrew/share/info'+$(if(${ENV:INFOPATH}){':'+${ENV:INFOPATH}})),[System.EnvironmentVariableTarget]::Process)
$ brew shellenv
set -gx HOMEBREW_PREFIX "/opt/homebrew";
set -gx HOMEBREW_CELLAR "/opt/homebrew/Cellar";
set -gx HOMEBREW_REPOSITORY "/opt/homebrew";
set -q PATH; or set PATH ''; set -gx PATH "/opt/homebrew/bin" "/opt/homebrew/sbin" $PATH;
set -q MANPATH; or set MANPATH ''; set -gx MANPATH "/opt/homebrew/share/man" $MANPATH;
set -q INFOPATH; or set INFOPATH ''; set -gx INFOPATH "/opt/homebrew/share/info" $INFOPATH;
```
The specific case presented in the mentioned discussion could be
mitigated by an additional level of indirection (`{{ output "fish" "-c"
"'brew shellenv'" | trim }}`), that requires that the running system
have the target shells installed, when they are not strictly necessary
with `brew shellenv`.
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
It looks like #7738 removed the default unintentionally. This adds it back.
For scripts that `set -u`, this will fail if $INFOPATH is not already set (`INFOPATH: unbound variable`). This provides an empty default, but one that will still satisfy the trailing colon requirement.
It currently switches on `$SHELL`, which points to the user's login shell. However, `shellenv` may be used in contexts where the running shell isn't `$SHELL` (e.g. csh-based `cron` scripts), and Linux desktop environments may set up user sessions in ways that trip up the current algorithm (see #7965 for an example). To work correctly in all circumstances and environments, its output should be determined by the context (calling shell) instead.
Fixes#7965.
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.
$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.
