If `/usr/local` is the prefix but not the repository (so bottles can be
used) then running `/usr/local/bin/brew` works great but
`$HOMEBREW_REPOSITORY/bin/brew` assumes the prefix is
`$HOMEBREW_REPOSITORY`. This is a pain when doing work on the Homebrew
repository and having e.g. `bin` in your `$PATH`. Improve this
behaviour so `bin/brew` knows how to handle this situation.
If `bin/brew` happens to be symlinked to `/brew`, `/bin/brew`, or some
similar location or (worse yet) Homebrew is installed to `/`, then
computation of the prefix and/or repository path could break down and
result in an invalid or empty path.
ClosesHomebrew/homebrew-core#2430.
This is inspired by `quiet_system` with basically the same implication
(suppress output), making the name a lot less confusing and avoiding a
clash with the `chdir` function defined in `Library/brew.sh`.
`bin/brew` is getting a bit bloated and it's annoying to open all of
`HOMEBREW_PREFIX` in your editor of choice and have it search through
the `Cellar`. Let's instead keep the bare minimum in `bin/brew` and
move the rest to `Library`.
ClosesHomebrew/homebrew#49185.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
This means that internal command aliases can be used for Bash commands
(such as the new, Bash-based `brew update`).
FixesHomebrew/homebrew#49182.
ClosesHomebrew/homebrew#49184.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Also, rename the existing updater to `update-ruby` to allow using as
a fallback. It will eventually be removed.
ClosesHomebrew/homebrew#49109.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
This should help to avoid collisions with external commands and other
shell functions in the future and is closer to what we do in Ruby, where
commands are namespaced by being methods of the `Homebrew` module.
We have asserted before that the 1st argument is the command name. No
need to pass it to the bash command, which will make the argument
handling for the command itself a bit easier.
Commands implemented in shell (bash) are supposed to be sourced from
`bin/bash` instead of being executed directly. Consequently, don't
expect the implementation files to be executable.
Otherwise when `bin/brew` is updated in-place Bash will carry on from
the offset and this can cause issues.
Thanks to `@UniqMartin` for pointing this out.
Everyone should be using a UTF-8 locale nowadays. Not using one causes
issues like `brew doctor` failing while checking symbolic links that
point at file names with non-ASCII characters, since OS X always uses
Unicode for the file system.
Rely on `locale charmap` to detect the currently selected encoding and
if that's not UTF-8, override the user's choice (if any) by setting
`LC_ALL` to `en_US.UTF-8`, the assumption being that every system has a
usable `en_US.UTF-8` locale installed.
FixesHomebrew/homebrew#44744.
ClosesHomebrew/homebrew#47247.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
For typical installations where `brew` is not a symbolic link, this
reduces the number of processes that need to be spawned.
ClosesHomebrew/homebrew#46269.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
This reduces the number of processes that need to be forked. If
libtool's `config.guess` is to be trusted, there was never another
spelling/capitalization other that `Darwin`.
This very slightly reduces duplication and the risk of inconsistency by
exporting in one branch, but not the other. By putting all the `export`
statements right before the `exec` it is more obvious what is passed on.
While `var=$(<command>)` is perfectly valid and won't create any issues,
it is often surprising for less shell-savvy users. Quoting these cases
like in all other instances makes the code more uniform, helps to avoid
future mistakes, and has no downsides.
Make it no longer possible to override e.g. `brew install` with a
script if there is already a built-in Homebrew command named
`brew install`.
References Homebrew/homebrew#17673
