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
This allows us to force using the system Ruby on OSX but allow
the development of Homebrew for Linux or Windows to not rely
on OSX paths.
ClosesHomebrew/homebrew#17548.
Let's not show weird error messages when user interrupts during various stages of brew initialization.
Tested by doing `for x in $(brew search); do brew install $x; done` and pressing CTRL-C at random short intervals.
Fixes a case where brew would find commands with wrongly-capitalized
user input on case-insensitive systems, then error out with a confusing
message when an invalid method was sent to Homebrew. e.g.:
> brew Update
Error: undefined method `Update' for Homebrew:Module
We don't want bug reports about this crap, even though the user REALLY should listen to the warning message. What actually happens is they blame us instead.
This kind of warning in particular:
warning: Insecure world writable dir /usr/local/bin in PATH
Rationale: some users insist on replacing the /usr/bin/ruby symlink
to point to another ruby on their system, which may break homebrew.
Use the full Framework path instead, which is less likely to be tampered with.
This also reorganizes the brew --config checks to reflect the different path.
FixesHomebrew/homebrew#12009.
ClosesHomebrew/homebrew#12333.
Signed-off-by: Misty De Meo <mistydemeo@gmail.com>
'which' only returns a Pathname or nil, and doesn't care about anything
sent to stderr, so just silence it by default and combine the two
methods.
ClosesHomebrew/homebrew#12115.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
