when i tried to install, i got a message `_bash-it-pluralize-component` command not found; after checking `utilities.bash` the correct function name was `_bash-it-component-pluralize`
Don't use `local -n var` so that we can support v3.2...
Note: function names and variable names are different namespaces, so we can have a variable named the same as the function...which makes it really easy to predict default names for results when returning this way.
...to replace `_set-prefix-based-on-path()` in `scripts/reloader`.
Deliberately does not use `_bash-it-get-component-name-from-path()`/`_bash-it-get-component-type-from-path()` as we need some of the intermediate state and would have to reimplement anyway.
Alsö, fix tests to load `lib/colors` instead of `lib/appearance`...wut
Alsö, `short-circuit _has_colors()`: If we already looked up colors, and we already have them, then don't run `tput` again.
My apologies to future `git blame` hunters ♥
Create an array `_bash_it_library_finalize_hook` and loop at the end of the main `bash_it.sh` to run each element in the array.
The purpose here is to run some command after everything else has been loaded. For example, the appearance lib checks for executables for SCM commands, but `$PATH` may be altered after appearance has loaded and therefore some available commands may never be discovered. Therefore, create `_bash_it_appearance_scm_init()` and add it to the hook. It will re-check at end of `bash_it.sh` just before prompt is first displayed.
Load the completion script from the subversion package installed on the system, instead of bundling a copy. This addresses Bash-it/bash-it#1818.
NOTE: If `completions/system` is enabled, then it will load this same file anyway automatically.
Symlink `/test_lib/bats-core/test/fixtures/parallel/suite/helper.bash` references a not-existing file, but it's in a submodule so I can't just fix it. Exclude it from `rsync` in `setup_test_fixture()`.
Test was failing only on Mac OS X for some reason, so refactor a little. It turned out to be due to explicitly setting `$HOME` *after* loading the plugin.
Literally copying a line from the source to be tested is perhaps not the best way to test that code. 😉
That said, we do want to verify that the function was actually loaded.
TODO: actually test the function.
For testing non-core files, just `load ../test_helper_libs` after `load ../test_helper` instead of trying to guess which libs must be loaded, in which order, for testing to succeed.
`_command_exists` spews log messages, so our test log is littered with `_log_debug not found`. This fixes that too.
souhaiebtar
Noah Gorny
John D Pell