Allows for setting "COMMAND_DURATION_MIN_SECONDS" to more than 60 seconds without adding to prompt. Previously always showed with lengths over 60 seconds regardless of setting.
* fix (plugins): enable interpretation of backslash escapes in colors
* fix (lint): disable SC2317 in install.sh
* fix (lint): SC2086 in agnoster theme
* fix (lint): remove exit from install.sh as it is already implemented in the calling function
* Use C style strings when checking for invalid alias characters
Before, the '\n' would be interpreted as 'n' meaning that any alias
who's command contained the letter 'n' would incorrect be skipped.
* No need to escape characters in this context
Escaping was just adding \ to the list multiple times
Co-authored-by: David Farrell <davidpfarrell+github@gmail.com>
Git can list local branches, remote branches, and both of them together.
Let's use the long form of the options to make the aliases quicker to understand.
As agreed in PR #2159, we introduce gbl and replace gba/gbr by gbla/gblr.
gbl/gbla/gblr allow wildcard arguments for filtering branch names.
Isolates fetching of EPOCHREALTIME to a function which sets LC_ALL=en_US.UTF-8.
This ensures that the value is in decimal format, regardless of runtime locale.
bug: Hide duration when no command executed
Ensures that the -E or -F option, when used, is the first option
* i.e. grep -oE => grep -E -o
Updates _bash-it-grep to invoke grep with just the provided arguments
* This function was (and still is) unused, but decided this new functionality was actually more useful
Introduces _bash-it-fgrep to invoke grep -F
Removes type -P egrep from the _bash-it-*grep functions
For usages that were already going to be modified, use -F if appropriate
* Does not touch grep usages that may have benefited from -F, but were not otherwise considered for this PR
Adds shellcheck header to modified .bash files that didn't already have it
This regression was introduced in ea2002a.
Before this commit, when the provided project was unique under all the
project paths, the command automatically change the directory to it.
Currently this is no more the case.
If there are many project paths set, then the project path menu is shown
at every call.
This PR solves this issue.
Signed-off-by: Eric Villard <dev@eviweb.fr>
* Add a 'theme' for OMP, so the internal themes don't clash with it.
* Add theme to clean_files
* Add screenshot to the docs
* Correct the name of the default theme in the docs.
* keeping it cleaner
Co-authored-by: Ira Abramov <github@ira.abramov.org>
Use `$EPOCHREALTIME` (or `$SECONDS`) built-in variable provided by Bash instead of `date +%s`. We're only measuing the difference in seconds, so avoid both the binary invocation as well as the subshell.
Alsö, Reduce environmental pollution by not exporting every variable, and unsetting when done.
Change variable names to match lib/command-duration
Remove `preexec_return_notification()` in favor of `lib/command-duration`'s `_command_duration_pre_exec()`.
This should now use the same preexec hook and variables as the theme library `command_duration`.
tests: handle nanoseconds
Fallback to `$SECONDS` for older versions of _Bash_.
Instead of shortcircuiting the definition, just short-circuit the function. This allows the variable to be set later, e.g. on theme change.
Calculate the position (from 1 to 12) of the hour hand on the clock emoji used for the _command_duration string.
Expressly handle COMMAND_DURATION_COLOR as blank when undefined.
My apologies to future `git blame` hunters ♥
Use the "short" host name by default (`\h`), not the fully qualified domain name (`\H`)...
lib/theme: don't redefine battery_char()
Combine the two definitions for `battery_char()` so the second one doesn't just overwrite the first one. Do one or the other, not both.
Don't evaluate if `battery_percentage()` is available at load time, evaluate it at run time.
Don't run `date` for `$THEME_TIME_FORMAT`, use `\D{fmt}`.
Run the test *files* in parallel, but not the tests *within* the files. This can be reverted after configuration (i.e., `$BASH_IT/enabled` et al) lives *outside* the repo.
- Use a POSIX-compliant/portable extended regular expression to match on word-boundaries, rather than guessing which regex library `bash` was linked against. See https://stackoverflow.com/a/12696899/555333 for explanation and code suggestion.
Rewrite comment on disabling the `DEBUG` trap in subshells, which is now handled upstream as of rcaloras/bash-preexec#26.
Alsö, fix the guard variable assignment to allow it to be overridden elsewhere (e.g., for testing).
When the file is being re-created, we write to it, instead of appending to
it. So, the rm here is unnecessary and prevents users from linking the profile
file to another location that is potentially under version control. For
instance, once could link to a profile file located at
"$BASH_IT_CUSTOM/profiles/*.bash_it".
- Replace `echo -e` with `printf` in `_bash-it-log-message()`.
- Local positional parameters to allow for defaults.
- Use `if`/`then` properly.
- Clean up use of `$BASH_IT_LOG_PREFIX` slightly (eliminate duplicate colons).
Alsö, remove impossible alias. If someone wants it, they can write the function, but since aliases literally don't work this way it seems obvious that nobody has ever used it.
* 'master' of https://github.com/Bash-it/bash-it: (22 commits)
main: variable name cleanup
lib/history: new functions `_bash-it-history-auto-*()`
plugin/history*search: no need to load after `plugin/history`
plugin/history-eternal: Use `readonly` instead of `export`
plugin/history: don't use `export`
lib/preview: add full completion
lib/helpers: add `preview` to `bash-it` spaghetti
lib/preview: refactor into a function
completion/system: correctly load version when not linked
main: adopt `_bash-it-log-prefix-by-path()`
main: Glob for *.bash properly when path contains spaces
completion/aliases: rename init function
test/battery: require matching battery identifier
test/battery: add multiple-battery edge case
plugin/battery: split `upower` to two variables
completion/alias: add stub file
completion/alias: fix tests
completion/alias: rename
completion/alias: `shfmt` && `shellcheck`
completion/alias: eliminate use of `eval`
...
Two new functions `_bash-it-history-auto-save()` and `_bash-it-history-auto-load()`, which append new history to disk and load new history from disk, respectively.
See bash-it/bash-it#1595 for discussion.
...and hide errors relating to setting already-readonly variables.
`plugin/history-eternal` does not need to force loading after `plugin/history` because both plugins will play nicely with read-only variables, and since we're overwritting and marking read-only then the intended result survives no matter which loads first.
plugin/history-eternal: require Bash v4.3+
Unlimited history is only possible in _Bash_ version 4.3 and up
This allows future use like `bash-it preview`. Alsö, allows to use `$BASH_PREVIEW` to specify a particular theme to preview instead of just doing all of them.
- `shfmt`, `shellcheck`
- Clean up legacy/compatibility code to simpler control flow
- Move theme stuff down to where themes are handled
- Don't use `**` as _Bash It_ has never before set `globstar`; this eliminates varying behavior by environment; this alsö fixes users having any not-enabled themes under their custom dir.
- Lose weird Mac-specific alternate shell startup file (Bash loads startup files on Mac the same as it does on any other *nix system.)
- Place `composure.sh` init all in one place
- remove 10-years-deprecated backwards compatibility: Deprecated in `b59ee658f78ec6ff8c6c2754216e0322b7fe18e2` dated 2011-10-29.
There is no reason for this to be in the `plugins` directory, it just needs to have a load priority sufficiently high that it runs after any aliases are defined.
Improve `_bash-it-erase-term()`, `_bash-it-flash-term()`, `_bash-it-rewind()`, `_bash-it-search-result()`, and `_bash-it-search-component()`. Minor tweaks to `_bash-it-is-partial-match()`, and `_bash-it-search()`.
1. `$text_black` isn't a parameter provided by _Bash It_. Typo?
2. `$bold_yellow` is meant for prompt strings and putputs `\[`; ditto `$bold_red`.
3. The color was never returned to normal after.
This reverts commit 2a3fde2b14 but does *not* restore the previous variables. Those are still provided by `lib/colors`.
This plugin exists for anyone who likes the metaprogramming adventure of computing colors dynamically rather than using hard-coded value. Potentially this could be used by themes, or possibly by a theme color-scheme randomizer?
This reverts bash-it/bash-it#99, a metaprogramming adventure in terminal color code escape computation. It was functionally reverted in bash-it/bash-it#699; I'm just finishing the job.
When `upower --enumerate | grep -i BAT` returns multiple lines of results (which are file paths),
the added quotation (from commit 3cb5f3f7e6) concatenates them all to provide an invalid path.
Thus to make the plugin work as before the commit,
take only the first line of the results.
Bash loads initialization files on Mac just the same as it does on Linux or WSL. Our previous assumptions were wrong, and my fix was alsö wrong because I made more assumptions!
This patch eliminates the assumptions. Literally just load either the startup file the shell started with, or fall back to `~/.bashrc`. Don't check `shopt -q login_shell` and don't check `$OSTYPE` or anything else.
Define the helper functions for `bash-preexec.sh` immediately after importing it, rather than in `lib/theme`.
- `__check_precmd_conflict()` and `save_append_prompt_command()` are generally useful and not theme-specific.
- Add matching `__check_preexec_conflict()` and `safe_append_preexec()`.
...to `_bash-it()`.
The norm is for the completion function for, e.g., `teh_cmd`. to be named with the same name and a prepended underscore, i.e. `_teh_cmd`. This alsö reduces namespace confusion, which will be relevant in a future patch.
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`
Quote some parameter uses that don't strictly require it, but since Bash needs so many quotes everywhere else my brain worms feel better when these are quoted too.
lib/helpers: simplify some quote escapes
Replace weird non-globs with array and loop, as suggested by `shellcheck`. Alsö, simplify several constructs to eliminate external binaries.
Alsö, see mvdan/sh issue 558
lib/helpers: unbound positional parameters
- Improve `pushd`/`popd` somewhat
- local some parameters
- Lose weird Mac-specific alternate shell startup file (Bash loads startup files on Mac the same as it does on any other *nix system.)
Quote things, SC2268, SC2143, SC2181, SC2162, SC2016, SC2013, &c.
Rewrite globbing per `shellcheck`’s SC2013, and alsö s/typeset/local/g. Eliminate `compgen` where possible.
Alsö: use the existing utility functions `_bash-it-get-component-type-from-path` and `_bash-it-get-component-name-from-path`, which just use parameter substitution anyway. Why was `sed` here?
Alsö, don't add not-existing directories to `$PATH` in `pathmunge()`.
Finally, merge PR #1865 from NoahGorny...and clean it a bit...
- Don't write to disk, just pipe.
- Don't loop, just do all functions.
Performance of old implementation on my system:
```
real 0m9.996s
user 0m5.318s
sys 0m9.126s
```
Performance of new implementation on my system:
```
real 0m0.052s
user 0m0.069s
sys 0m0.025s
```
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.
Lose a couple of useless `echo`s/subshells.
Alsö, lose the incorrect VIM modeline from the bottom. Our formatting standard is specified in `$BASH_IT/.EditorConfig`.
Use shell functionality to avoid invoking external binaries, and quote some stuff. Alsö, use $EDITOR and related variables in order to fall through if some aren't defined.
Move the test for whether `plugin/todo` is enabled inside the function, and remove the alias from there.
Alsö, respect `$XDG_STATE_HOME` and move the old `~/.t` file if it exists.
plugins/osx: dead code removal
No need for gymnastics to determine if variable had been exported priort to modification. If it was, then it still is. See man bash(1).
This reverts commit 2c8ee40566.
- _Shellcheck_ documentation for the [`source-path`]( https://github.com/koalaman/shellcheck/wiki/Directive#source-path ) directive indicates this is correct usage. We're `source`ing the `bash-preexec.sh` file from inside the `vendor/github.com/rcaloras/bash-preexec` directory. If we used the [`source`]( https://github.com/koalaman/shellcheck/wiki/Directive#source ) directive, then the full complete path to the file itself would need to be specified.
- Fix `disable=1090` to `disable=SC1090` and remove duplicate lines since this `shellcheck` directive will apply to the entire if-ladder.
- Disabling `SC2154` is almost never appropriate. In this case, several `_git_bash_completion*` variables are expressly assigned in this file, so there is no "unknown" to ignore.
Aside: the `${!_git_bash_completion@}` construct will expand to all variables starting with the previx `_git_bash_completion`, so this line is just a shorthand way to clear all our variables concisely without forgetting any.
- remove the use of redundant cite
- minor cleanups to history.plugin.bash
- set explicit load orders for history-search and history-substring-search
- add new plugin history-eternal
- replace superfluous trap for managing HISTTIMEFORMAT changes
I have a repo with many other branches that contain the string `main`,
but our default branch is still master. This grep was seeing those other branches
and deciding that my default branch was `main`. This tighter regex
fixes that behavior for me.
By setting `__bp_delay_install`, we avoid any immediate initialization at all. We then override two troublesome functions before calling `__bp_install_after_session_init()`.
The `__bp_install_after_session_init()` function doesn't enable the DEBUG trap, just sets `$PROMPT_COMMAND` to include `__bp_install()`, so the actual final `$PROMPT_COMMAND` is not finished, and DEBUG trap set, until after the first prompt is displayed.
The existing function `_bash-it-grep()` is weird. New function `_bash-it-egrep()` just does the thing without requiring two subshells and manual invocation.
Use $XDG_CACHE_HOME environment constant instead of placing a tmp/cache folder inside the bash-it data repo. If not defined, fall back to current behavior.
This resolvesBash-It/Bash-It#1904.
No need to `rm` when we overwrite the file the line after next. Alsö, use `>|` in case the user sets `noclobber`; we do expressly intend to overwrite the file in this case.
The tilde should not have been escaped, and in fact I did not have it escaped in my main branch, but the PR I submitted did have it escaped and...now it shows up in the prompt line for all the PowerLine themes... oops.
This commit cleans up the pyenv plugin to follow the newer conventions of the
other *env plugins, as well as addresses the changes made to pyenv for PATH
munging.
* lib/utilities: shellcheck
SC2059
* lib/utilities: fix `_bash-it-get-component-type-from-path()`
Account for plugins with names that contain periods.
* lib/utilities: fix `_bash-it-array-dedup()`
Use fewer subprocesses and newline-delimited not space-delimited.
* lib/utilities: fix `_bash-it-component-list()`
Use fewer subprocesses and return newline-delimited, not space-delimited.
* lib/utilities: fix `_bash-it-component-list-matching()`
Use `sort -u` instead of `sort | uniq`
* lib/utilities: fix `_bash-it-component-list-enabled()`
Use fewer subprocesses, return newline-delimited instead of space-delimited, and use `sort -u` instead of `uniq | sort`
* lib/utilities: fix `_bash-it-component-list-disabled()`
Use fewer subprocesses, return newline-delimited instead of space-delimited, and use `sort -u` instead of `uniq | sort`
* lib/utilities: fix `_bash-it-grep()`
1. Executing `'/usr/bin/grep'` does *not* return the path to grep...
2. use `type -p` instead of external binary `which`.
3. Simplify parameter definition.
4. Why was there a space after `%s`?
* lib/utilities: use `_bash-it-grep`
Alsö, lose a spurious `cat`
* lib/utilities: lint `_bash-it-component-help`
* lib/utilities: lint `_bash-it-component-cache-file()`
* lib/utilities: `shfmt`
My apologies to future `git blame` hunters ♥
* lib/helpers: fix `_bash-it-get-component-name-from-path()`
Use `${BASH_IT_LOAD_PRIORITY_SEPARATOR}`
* plugins/base: code style improvements
Quote variables, use $@ and $array[@] instead of $*, typeset some integers, remove unneccesasary binary invocation, use shell features when possible, remove `eval`, &c.
* plugins/base: conditional function definitions
Instead of functions failing when required tools aren't installed, just don't define the function.
Alsö, don't redefine del() if it already exists.
* plugins/base: rewrite `usage()`
Reimplement disk usage function using Bash syntax and simpler layout, without having to invoke an external binary.
* plugins/base: revamp `quiet()`
New implementation that is even quieter.
* plugins/base: `myip()`
* plugins/base: `pickfrom()`
* plugins/base: `passgen()`
Fix `passgen()` to not need `tr`, remove one subshell, and eliminate a useless `echo`.
* plugins/base: `mkcd()`
* plugins/base: `mkiso()`
* plugins/base: remove `banish-cookies()`
Adobe Flash is gone with the wind. Alsö, this would be something someone would do *once* and shouldn't be a function...
* plugins/base: `lsgrep` is SC2010
The `lsgrep()` function is *itself* explicitly forbidden by `shellcheck` rule SC2010.
Alsö, s/`$*`/`$@`
* plugins/base: `mkiso()`
Expressly handle unbound parameters.
* plugins/base: remove `command_exists`
* plugin/base: lint SC2154 && SC2144
Newly undisabled `shellcheck` rules
* plugin/base: import libs for tests
* plugin/base: `shfmt`
Apply `shfmt` using current project settings. My apologies to future `git blame` hunters. ♥
- Remove limitation on OS.
- Add search for Mac OS X developer tools locations by using `xcrun` instead of trying to guess paths.
- Add search for locations based on path of `$GIT_EXE` (set by `lib/theme`).
Addresses bash-it/bash-it#1632
And use `_log_warning`.
Alsö, code style cleanup: quote things, handle unbound parameters, &c.
Alsö alsö, short-circuit if not installed or inadequate _Bash_ version.
Short-circuit the loader rather than indenting nearly the whole file.
ALSÖ, assign the `_pip_completion()` handler directly once it's loaded so that we get out of the way once we load it.
Convert from indented if-block to return then unindented code. This should have basically one line change at the top, one line removed at the bottom, and then all whitespace.
Convert from indented if-block to return then unindented code. This should have basically one line change at the top, one line removed at the bottom, and then all whitespace.
New function to do a search looking for a sibling to a parent of the current directory, for example to find `../../.git` to indicate that `$PWD` is inside a git repository.
* CI: disable Ubuntu 16.04 as it's EOL
https://github.blog/changelog/2021-04-29-github-actions-ubuntu-16-04-lts-virtual-environment-will-be-removed-on-september-20-2021/
* main: lint false positive
* install: lint
* plugins/cmd-returned-notify: don't `export`
* plugins/xterm: lint
* plugins/git: lint
* plugins/goenv: lint
* plugins/alias-completion: lint false positives
* plugins/alias-completion: fix SC2155, SC2154
Declare `locals` at the top of the function
* completion: lint completions using `bash_completion` functions
Match the style of the existing code
* completion/knife: lint false positives
* completion/knife: lint
* completion/sdkman: lint
* completion/composer: lint
* Move `.shellcheckrc` under `themes/`
* lib/theme: fix SC2155, SC2154, SC2034
* lib/colors: don't warn on unused variables
We assign a large number of variables here and they may or may not be used anywhere else, so disable SC2034 for this file (only).
Alsö disable SC2005 as the functions in this file were written before `printf` was invented and have to do some fancy metascripting to get escape sequences interpreted reliably. I’m not smart enough to fix this to use `printf`, so leave it for now.
* themes/agnoster: lint
* themes: disable SC2154 for colors
Each one of these themes will need it’s own fix for SC2154, possibly upstream.
Due to the way themes are, it's entirely normal to have a *lot* of false positives for SC2034. So much so, that I have to admit that it is probably just not worth linting for SC2034 despite my dislike of blanket ignore rules.
* themes: disable SC2154, fix SC2155
Each one of these themes will need it’s own fix for SC2154, possibly upstream.
Due to the way themes are, it's entirely normal to have a *lot* of false positives for SC2034. So much so, that I have to admit that it is probably just not worth linting for SC2034 despite my dislike of blanket ignore rules.
* Delete `.shellcheckrc`
* remove executable bit
Despite `indent_size` being set to `tab` by default, it turns out that we set `indent_size` to `2` for `*` at the top of this file. So, for everywhere else, explicitly set `indent_size` to the default (`tab`). This should achieve the goal of my last patch to `.editorconfig`.
Convert `var=${dirname $filename)` to `var="${filename%/*}` in cases where there is no ambiguity.
Make sure that the path in `$BASH_IT` is absolute because this path gets embedded in the template `.bash_profile` file if selected by the user.
Wrap init code in a function and call the function immediately. Several plugins do this, and it allows us to more easily implement a hooks-based system in the future.
Alsö, avoid external binary `which`. Use built-in `type -P` instead. Uppercase `-P` forces a path search to avoid hashed matches and functions/aliases and whatnot.
Give up and accept defeat that bash-completion can't reasonably be audited for unbound parameters. Wrap invocation with disabling strictness, and restore after if it was enabled.
If the user hasn't defined BASH_IT_LOG_LEVEL, then the integer comparison fails. Handle it by defaulting to '1'.
If lib/log is loaded improperly, the BASH_IT_LOG_PREFIX may be undefined. Unlikely, but no harm in handling it too.
Likewise, if no theme is loaded, then $echo_green, $echo_normal, et al are not defined.
Check if `brew` is installed every time, and *unset* `$BASH_IT_HOMEBREW_PREFIX` if not found. This accounts for the edge-case of a user _uninstalling_ Homebrew without restarting the shell.
Use new function `_bash_it_homebrew_check()` in existing plugins and completions which look for Homebrew.
Alsö, use `$OSTYPE` instead of calling external `uname` binary.
New function `_bash_it_homebrew_check()` sets global variable `$BASH_IT_HOMEBREW_PREFIX` using `brew --prefix` if `brew` exists as a valid command. If `brew` isn't installed, then return failure.
Plugins can test for `brew` by calling this function and, if it succeeds, they can rely on `$BASH_IT_HOMEBREW_PREFIX` being defined properly.
Renamed the function to _bash-it_update_migrate_and_restart
Use pushd/popd instead of passing another parameter
Document the function so it will be clear that it does not return
When using tabs, `indent_size` should be set to `tab`, which is the default. Furthermore, `tab_width` (which is likely what was intended when `indent_size` was entered) should be left up to the user. If the user likes an 8-character indent, then let them. If they like 2-character indent size, then let them. Using tabs means that this all works normally for everyone, even if it's different on different screens.
* lib/helpers: use `$OSTYPE` instead of `$(uname)`
* plugins/osx: use `$OSTYPE` instead of `$(uname)`
* plugins/boot2docker: use `$OSTYPE` instead of `$(uname)`
* plugins/python: use `$OSTYPE` instead of `$(uname)`
* plugins/base: use `$OSTYPE` instead of `$(uname)`
Alsö, use `[[` instead of `[` as the former has less insane argument handling being shell syntax rather than a builtin command that must emulate being a real binary
* completion/brew: use `$OSTYPE` instead of `$(uname)`
* completion/git: use `$OSTYPE` instead of `$(uname)`
Alsö, use `[[` instead of `[`.
* completion/fabric: use `$OSTYPE` instead of `uname`
* theme/demula: use `$OSTYPE` instead of `$(uname)`
* theme/rana: use `$OSTYPE` instead of `$(uname)`
Need to use grep WITHOUT case-sensitivity. Otherwise results such as com.apple.iChat and com.apple.imagent won't be handled correctly and neither one can be completed.
Fixed another comparison that prevented "defaults read com.apple.iChat <complete>" from correctly returning the available defaults keys in that file.
Bash-completion supports pre-defining $BASH_COMPLETION as the path to the main script, so use that if it's defined.
Alsö, don't load homebrew's completion if we've successfully loaded one already.
Instead of using the profile.d version, just invoke the script. The profile.d script preemptively short-circuits if it thinks that bash-completions has already been loaded, which it does by using the $BASH_COMPLETION variable, which is expressly supported by upstream to specify the location of the script...so it will entirely be never loaded if this is set.
Fix the __powerline_duration_prompt: location & unused variable `prompt`
Remove the duration segment from powerline* theme defaults
Different color for duration prompt segment
This will ensure users will specify whether they want to overwrite the
backup or not, and check it even when we do silent installation
This does change the default behaviour and exits if the -f flag is not
specified and a backup is present.
55fdb9f Merge pull request #24 from bvberkum/pr-21
b360ca5 Use command name, not last argument as shell-name [#23]
5c458c9 22 - Document revise behavior with GUI editors
7de4304 Update LICENSE copyright
f784e3a Merge pull request #20 from akatrevorjay/pr/zsh-plugin
1901dbe Merge pull request #19 from DrVanScott/master
6bcbc7b Add zsh-style plugin for easy load
37bccee fix _typeset_functions_about for functions starting with a dash
27623a9 fix zsh specific issues
2efc446 glossary: list only functions containing 'about'
7899d11 glossary: call _typeset_functions only once
072856e shell(): Fix for cygwin environment
2dc31de avoid error message if gprintf does not exist
git-subtree-dir: vendor/github.com/erichs/composure
git-subtree-split: 55fdb9fa3cd0f181208a46d90da4d87d5b7e4351
This PR seeks to address several issues surrounding the go and goenv plugins.
The nature of goenv allows for a situation where the initial shell does not
point to a working go binary, and instead at the included shim script. The
result is that one must run reload after moving to a project directory with a
version file, however in doing so, PATH is updated, requiring they exit the
shell or risk lookup collisions and unexpected behavior.
This is solved by using preexec to check the version before changing
directories and restarting the shell if the version has changed. The exec
pattern is copied from _bash-it-restart, but is edited to support this specific
use case.
Additionally, tests have been uploaded and these are now being linted.
Added a vendored lib loading routine in bash-it.sh
Added documentation on how to vendor libs in bash-it
Added and fixed plugins using preexec
Added tests for two plugins
Removed the old preexec lib
sdkman has a specific output format for Java candidate since
there are multiple vendors and builds. For example, when running
`sdk list maven`, the format is a simple list like:
3.6.2
3.6.1
3.6.0
3.5.4
3.5.3
3.5.2
3.5.0
3.3.9
But for `sbt list java`, the output is a table like:
================================================================================
Vendor | Use | Version | Dist | Status | Identifier
--------------------------------------------------------------------------------
AdoptOpenJDK | | 15.0.1.j9 | adpt | | 15.0.1.j9-adpt
| | 15.0.1.hs | adpt | installed | 15.0.1.hs-adpt
...
Amazon | | 15.0.1 | amzn | | 15.0.1-amzn
| | 11.0.9 | amzn | | 11.0.9-amzn
...
Azul Zulu | | 15.0.1 | zulu | | 15.0.1-zulu
| | 15.0.1.fx | zulu | | 15.0.1.fx-zulu
...
Therefore, the completion script has to handle both formats.
* Optimized statement with REGEX by using `case`
REGEX is a great feature of BASH, but in this case it was energy
needlessly spent. A `case` statement suffices. Bring in REGEX when
you're going to make good use of it, otherwise it's just going to bog
down your code.
I also wanted to strip the ` || exit 1` on the last line, but I wasn't
sure if this file is meant to be sourced or not; if not, then exiting
like that is redundant because it will already exit with whichever
status the last command provides, unless `popd` specifically offers
unhelpful or no exit statuses.
* Optimize as before but with 2nd REGEX instance
This time is much like the last commit, so I won't repeat, but I will
say that you're using a double- or even triple-negative, which
obfuscates your goal. Where you were doing...
[ ! -n VAR ] &&
You were basically saying this convolution:
If it's true that it's not true that VAR is not empty.
Very confusing. Instead, I've opted for:
If it's true that Var is empty.
Makes immediate sense and is easier to parse, visually speaking.
* master:
github: Add no-response bot
Update contribution.rst
Add cargo completion
Add completion for pipx. (#1719)
Add github action to replace travis
Address some comments.
Add in_toolbox prompt to powerline themes
Update atomic.theme.bash
Add rustup completion to clean_files.txt
Add rustup completion
Move README to be under docs/
docs: Transition md files to support new rtd format
pre-commit: Exclude docs _build folder
Add aliases for GIT-SVN (rebase and dcommit)
* Add completion for pipx.
* Add pipx completion to clean_files.txt.
* Format pipx.completion.bash to match the project's coding style.
* Format pipx.completion.bash with ./lint_clean_files.sh.
[Toolbox](https://github.com/containers/toolbox) is an containerized
development environment. This commit adds a promot to powerline when it
is running inside a toolbox.
When contributing a new feature, a bug fix, a new theme, or any other change to Bash-it, please consider the following guidelines.
Most of this is common sense, but please try to stick to the conventions listed here.
## Issues
* When opening a new issue in the issue tracker, please include information about which _Operating System_ you're using, and which version of _Bash_.
* In many cases, it also makes sense to show which Bash-it plugins you are using.
This information can be obtained using `bash-it show plugins`.
* If the issue happens while loading Bash-it, please also include your `~/.bash_profile` or `~/.bashrc` file,
as well as the install location of Bash-it (default should be `~/.bash_it`).
* When reporting a bug or requesting a new feature, consider providing a Pull Request that fixes the issue or can be used as a starting point for the new feature.
Don't be afraid, most things aren't that complex...
## Pull Requests
* Fork the Bash-it repo, create a new feature branch from _master_ and apply your changes there.
Create a _Pull Request_ from your feature branch against Bash-it's _master_ branch.
* Limit each Pull Request to one feature.
Don't bundle multiple features/changes (e.g. a new _Theme_ and a fix to an existing plugin) into a single Pull Request - create one PR for the theme, and a separate PR for the fix.
* For complex changes, try to _squash_ your changes into a single commit before
pushing code. Once you've pushed your code and opened a PR, please refrain
from force-pushing changes to the PR branch – remember, Bash-it is a
distributed project and your branch may be in use already.
* When in doubt, open a PR with too many commits. Bash-it is a learning project
for everyone involved. Showing your work provides a great history for folks
to learn what works and what didn't.
## Code Style
* Try to stick to the existing code style. Please don't reformat or change the syntax of existing code simply because you don't like that style.
* Indentation is using spaces, not tabs. Most of the code is indented with 2 spaces, some with 4 spaces. Please try to stick to 2 spaces.
If you're using an editor that supports [EditorConfig](http://EditorConfig.org), the editor should automatically use the settings defined in Bash-it's [.editorconfig file](.editorconfig).
* When creating new functions, please use a dash ("-") to separate the words of the function's name, e.g. `my-new-function`.
Don't use underscores, e.g. `my_new_function`.
* Internal functions that aren't to be used by the end user should start with an underscore, e.g. `_my-new-internal-function`.
* Use the provided meta functions to document your code, e.g. `about-plugin`, `about`, `group`, `param`, `example`.
This will make it easier for other people to use your new functionality.
Take a look at the existing code for an example (e.g. [the base plugin](plugins/available/base.plugin.bash)).
* When adding files, please use the existing file naming conventions, e.g. plugin files need to end in `.plugin.bash`.
This is important for the installation functionality.
* When using the `$BASH_IT` variable, please always enclose it in double quotes to ensure that the code also works when Bash-it is installed in a directory that contains spaces in its name: `for f in "${BASH_IT}/plugins/available"/*.bash ; do echo "$f" ; done`
* Bash-it supports Bash 3.2 and higher. Please don't use features only available in Bash 4, such as associative arrays.
## Unit Tests
When adding features or making changes/fixes, please run our growing unit test suite to ensure that you did not break existing functionality.
The test suite does not cover all aspects of Bash-it, but please run it anyway to verify that you did not introduce any regression issues.
Any code pushed to GitHub as part of a Pull Request will automatically trigger a continuous integration build on [Travis CI](https://travis-ci.org/Bash-it/bash-it), where the test suite is run on both Linux and macOS.
The Pull Request will then show the result of the Travis build, indicating whether all tests ran fine, or whether there were issues.
Please pay attention to this, Pull Requests with build issues will not be merged.
Adding new functionality or changing existing functionality is a good opportunity to increase Bash-it's test coverage.
When you're changing the Bash-it codebase, please consider adding some unit tests that cover the new or changed functionality.
Ideally, when fixing a bug, a matching unit test that verifies that the bug is no longer present, is added at the same time.
To run the test suite, simply execute the following in the directory where you cloned Bash-it:
```bash
test/run
```
This command will ensure that the [Bats Test Framework](https://github.com/bats-core/bats-core) is available in the local `test_lib` directory (Bats is included as a Git submodule) and then run the test suite found in the [test](test) folder.
The test script will execute each test in turn, and will print a status for each test case.
When adding new test cases, please take a look at the existing test cases for examples.
The following libraries are used to help with the tests:
* Test Framework: https://github.com/bats-core/bats-core
* Support library for Bats-Assert: https://github.com/ztombol/bats-support
* General `assert` functions: https://github.com/ztombol/bats-assert
When verifying test results, please try to use the `assert` functions found in these libraries.
## Features
* When adding new completions or plugins, please don't simply copy existing tools into the Bash-it codebase, try to load/integrate the tools instead.
An example is using `nvm`: Instead of copying the existing `nvm` script into Bash-it, the `nvm.plugin.bash` file tries to load an existing installation of `nvm`.
This means an additional step for the user (installing `nvm` from its own repo, or through a package manager),
but it will also ensure that `nvm` can be upgraded in an easy way.
## Themes
* When adding a new theme, please include a screenshot and a short description about what makes this theme unique in the Pull Request's description field.
Please do not add theme screenshots to the repo itself, as they will add unnecessary bloat to the repo.
The project's Wiki has a _Themes_ page where you can add a screenshot if you want.
* Ideally, each theme's folder should contain a `README.md` file describing the theme and its configuration options.
This page summarizes a couple of rules to keep in mind when developing features or making changes in Bash-it.
## Debugging and Logging
### General Logging
While developing feature or making changes in general, you can log error/warning/debug
using `_log_error``_log_warning` and `_log_debug`. This will help you solve problems quicker
and also propagate important notes to other users of Bash-it.
You can see the logs by using `bash-it doctor` command to reload and see the logs.
Alternatively, you can set `BASH_IT_LOG_LEVEL` to `BASH_IT_LOG_LEVEL_ERROR`, `BASH_IT_LOG_LEVEL_WARNING` or `BASH_IT_LOG_LEVEL_ALL`.
### Log Prefix/Context
You can define `BASH_IT_LOG_PREFIX` in your files in order to a have a constant prefix before your logs.
Note that we prefer to uses "tags" based logging, i.e `plugins: git: DEBUG: Loading git plugin`.
## Load Order
### General Load Order
The main `bash_it.sh` script loads the frameworks individual components in the following order:
* `lib/composure.bash`
* Files in `lib` with the exception of `appearance.bash` - this means that `composure.bash` is loaded again here (possible improvement?)
* Enabled `aliases`
* Enabled `plugins`
* Enabled `completions`
* `themes/colors.theme.bash`
* `themes/base.theme.bash`
* `lib/appearance.bash`, which loads the selected theme
* Custom `aliases`
* Custom `plugins`
* Custom `completions`
* Additional custom files from either `$BASH_IT/custom` or `$BASH_IT_CUSTOM`
This order is subject to change.
### Individual Component Load Order
For `aliases`, `plugins` and `completions`, the following rules are applied that influence the load order:
* There is a global `enabled` directory, which the enabled components are linked into. Enabled plugins are symlinked from `$BASH_IT/plugins/available` to `$BASH_IT/enabled` for example. All component types are linked into the same common `$BASH_IT/enabled` directory.
* Within the common `enabled` directories, the files are loaded in alphabetical order, which is based on the item's load priority (see next item).
* When enabling a component, a _load priority_ is assigned to the file. The following default priorities are used:
* Aliases: 150
* Plugins: 250
* Completions: 350
* When symlinking a component into the `enabled` directory, the load priority is used as a prefix for the linked name, separated with three dashes from the name of the component. The `node.plugin.bash` would be symlinked to `250---node.plugin.bash` for example.
* Each file can override the default load priority by specifying a new value. To do this, the file needs to include a comment in the following form. This example would cause the `node.plugin.bash` (if included in that file) to be linked to `225---node.plugin.bash`:
```bash
# BASH_IT_LOAD_PRIORITY: 225
```
Having the order based on a numeric priority in a common directory allows for more flexibility. While in general, aliases are loaded first (since their default priority is 150), it's possible to load some aliases after the plugins, or some plugins after completions by setting the items' load priority. This is more flexible than a fixed type-based order or a strict alphabetical order based on name.
These items are subject to change. When making changes to the internal functionality, this page needs to be updated as well.
## Plugin Disable Callbacks
Plugins can define a function that will be called when the plugin is being disabled.
The callback name should be `{PLUGIN_NAME}_on_disable`, you can see `gitstatus` for usage example.
[](https://gitter.im/Bash-it/bash-it?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
**Bash-it** is a collection of community Bash commands and scripts for Bash 3.2+.
(And a shameless ripoff of [oh-my-zsh](https://github.com/robbyrussell/oh-my-zsh) :smiley:)
Includes autocompletion, themes, aliases, custom functions, a few stolen pieces from Steve Losh, and more.
Bash-it provides a solid framework for using, developing and maintaining shell scripts and custom commands for your daily work.
If you're using the _Bourne Again Shell_ (Bash) regularly and have been looking for an easy way on how to keep all of these nice little scripts and aliases under control, then Bash-it is for you!
Stop polluting your `~/bin` directory and your `.bashrc` file, fork/clone Bash-it and start hacking away.
- [Contributing](#contributing)
- [Installation](#installation)
- [Install Options](#install-options)
- [via Docker](#install-using-docker)
- [Updating](#updating)
- [Help](#help-screens)
- [Search](#search)
- [Syntax](#syntax)
- [Searching with Negations](#searching-with-negations)
- [Using Search to Enable or Disable Components](#using-search-to-enable-or-disable-components)
- [Disabling ASCII Color](#disabling-ascii-color)
- [Custom scripts, aliases, themes, and functions](#custom-scripts-aliases-themes-and-functions)
- [Themes](#themes)
- [Uninstalling](#uninstalling)
- [Misc](#misc)
- [Help Out](#help-out)
- [Contributors](#contributors)
## Contributing
Please take a look at the [Contribution Guidelines](CONTRIBUTING.md) before reporting a bug or providing a new feature.
The [Development Guidelines](DEVELOPMENT.md) have more information on some of the internal workings of Bash-it,
please feel free to read through this page if you're interested in how Bash-it loads its components.
## Installation
1. Check out a clone of this repo to a location of your choice, such as
2. Run `~/.bash_it/install.sh` (it automatically backs up your `~/.bash_profile` or `~/.bashrc`, depending on your OS)
3. Edit your modified config (`~/.bash_profile` or `~/.bashrc`) file in order to customize Bash-it.
4. Check out available aliases, completions, and plugins and enable the ones you want to use (see the next section for more details).
### Install Options
The install script can take the following options:
* `--interactive`: Asks the user which aliases, completions and plugins to enable.
* `--silent`: Ask nothing and install using default settings.
* `--no-modify-config`: Do not modify the existing config file (`~/.bash_profile` or `~/.bashrc`).
When run without the `--interactive` switch, Bash-it only enables a sane default set of functionality to keep your shell clean and to avoid issues with missing dependencies.
Feel free to enable the tools you want to use after the installation.
When you run without the `--no-modify-config` switch, the Bash-it installer automatically modifies/replaces your existing config file.
Use the `--no-modify-config` switch to avoid unwanted modifications, e.g. if your Bash config file already contains the code that loads Bash-it.
**NOTE**: Keep in mind how Bash loads its configuration files,
`.bash_profile` for login shells (and in macOS in terminal emulators like [Terminal.app](http://www.apple.com/osx/apps/) or
[iTerm2](https://www.iterm2.com/)) and `.bashrc` for interactive shells (default mode in most of the GNU/Linux terminal emulators),
to ensure that Bash-it is loaded correctly.
A good "practice" is sourcing `.bashrc` into `.bash_profile` to keep things working in all the scenarios.
To achieve this, you can add this snippet in your `.bash_profile`:
```
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
```
Refer to the official [Bash documentation](https://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files) to get more info.
### Install using Docker
You can try Bash-it in an isolated environment without changing any local files via a [Docker](https://www.docker.com/) Container.
(Bash Shell v4.4 with Bash-it, [bats](https://github.com/sstephenson/bats),and bash-completion based on [Alpine Linux](https://alpinelinux.org/)).
`docker pull ellerbrock/bash-it`
Have a look at our [bash-it-docker repository](https://github.com/Bash-it/bash-it-docker) for further information.
### Updating
To update Bash-it to the latest stable version, simply run:
```bash
bash-it update stable
```
If you want to update to the latest dev version (directly from master), run:
```bash
bash-it update dev
```
If you want to update automatically and unattended, you can add the optional
`-s/--silent` flag, for example:
```bash
bash-it update dev --silent
```
If you are using an older version of Bash-it, it's possible that some functionality has changed, or that the internal structure of how Bash-it organizes its functionality has been updated.
For these cases, we provide a `migrate` command:
```bash
bash-it migrate
```
This command will automatically migrate the Bash-it structure to the latest version.
The `migrate` command is run automatically if you run the `update`, `enable` or `disable` commands.
## Help Screens
```bash
bash-it show aliases # shows installed and available aliases
bash-it show completions # shows installed and available completions
bash-it show plugins # shows installed and available plugins
bash-it help aliases # shows help for installed aliases
bash-it help completions # shows help for installed completions
bash-it help plugins # shows help for installed plugins
```
## Search
If you need to quickly find out which of the plugins, aliases or completions are available for a specific framework, programming language, or an environment, you can _search_ for multiple terms related to the commands you use frequently.
Search will find and print out modules with the name or description matching the terms provided.
### Syntax
```bash
bash-it search term1 [[-]term2] [[-]term3]....
```
As an example, a ruby developer might want to enable everything related to the commands such as `ruby`, `rake`, `gem`, `bundler`, and `rails`.
Search command helps you find related modules so that you can decide which of them you'd like to use:
```bash
❯ bash-it search ruby rake gem bundle irb rails
aliases: bundler rails
plugins: chruby chruby-auto ruby
completions: bundler gem rake
```
Currently enabled modules will be shown in green.
### Searching with Negations
You can prefix a search term with a "-" to exclude it from the results.
In the above example, if we wanted to hide `chruby` and `chruby-auto`,
Anything in the custom directory will be ignored, with the exception of `custom/example.bash`.
Alternately, if you would like to keep your custom scripts under version control, you can set `BASH_IT_CUSTOM` in your `~/.bashrc` to another location outside of the `$BASH_IT` folder.
In this case, any `*.bash` file under every directory below `BASH_IT_CUSTOM` folder will be used.
## Themes
There are over 50+ Bash-it themes to pick from in `$BASH_IT/themes`.
The default theme is `bobby`.
Set `BASH_IT_THEME` to the theme name you want, or if you've developed your own custom theme outside of `$BASH_IT/themes`,
point the `BASH_IT_THEME` variable directly to the theme file.
To disable theming completely, leave the variable empty.
You can easily preview the themes in your own shell using `BASH_PREVIEW=true bash-it reload`.
If you've created your own custom prompts, we'd love it if you shared them with everyone else! Just submit a Pull Request.
You can see theme screenshots on [wiki/Themes](https://github.com/Bash-it/bash-it/wiki/Themes).
**NOTE**: Bash-it and some themes use UTF-8 characters, so to avoid strange behavior in your terminal, set your locale to `LC_ALL=en_US.UTF-8` or the equivalent to your language if it isn't American English.
## Uninstalling
To uninstall Bash-it, run the `uninstall.sh` script found in the `$BASH_IT` directory:
```
cd $BASH_IT
./uninstall.sh
```
This will restore your previous Bash profile.
After the uninstall script finishes, remove the Bash-it directory from your machine (`rm -rf $BASH_IT`) and start a new shell.
## Misc
### Bash Profile Aliases
Bash-it creates a `reload` alias that makes it convenient to reload
your Bash profile when you make changes.
Additionally, if you export `BASH_IT_AUTOMATIC_RELOAD_AFTER_CONFIG_CHANGE` as a non-null value,
Bash-it will automatically reload itself after activating or deactivating plugins, aliases, or completions.
### Prompt Version Control Check
Bash-it provides prompt themes with the ability to check and display version control information for the current directory.
The information is retrieved for each directory and can slow down the navigation of projects with a large number of files and folders.
Turn version control checking off to prevent slow directory navigation within large projects.
Bash-it provides a flag (`SCM_CHECK`) within the `~/.bash_profile` file that turns off/on version control information checking and display within all themes.
Version control checking is on by default unless explicitly turned off.
Set `SCM_CHECK` to 'false' to **turn off** version control checks for all themes:
* `export SCM_CHECK=false`
Set `SCM_CHECK` to 'true' (the default value) to **turn on** version control checks for all themes:
* `export SCM_CHECK=true`
**NOTE:**
It is possible for themes to ignore the `SCM_CHECK` flag and query specific version control information directly.
For example, themes that use functions like `git_prompt_vars` skip the `SCM_CHECK` flag to retrieve and display git prompt information.
If you turned version control checking off and you still see version control information within your prompt, then functions like `git_prompt_vars` are most likely the reason why.
### Git prompt
Bash-it has some nice features related to Git, continue reading to know more about these features.
### Repository info in the prompt
Bash-it can show some information about Git repositories in the shell prompt: the current branch, tag or commit you are at, how many commits the local branch is ahead or behind from the remote branch, and if you have changes stashed.
Additionally, you can view the status of your working copy and get the count of *staged*, *unstaged* and *untracked* files.
This feature is controlled through the flag `SCM_GIT_SHOW_DETAILS` as follows:
Set `SCM_GIT_SHOW_DETAILS` to 'true' (the default value) to **show** the working copy details in your prompt:
* `export SCM_GIT_SHOW_DETAILS=true`
Set `SCM_GIT_SHOW_DETAILS` to 'false' to **don't show** it:
* `export SCM_GIT_SHOW_DETAILS=false`
**NOTE:** If using `SCM_GIT_SHOW_MINIMAL_INFO=true`, then the value of `SCM_GIT_SHOW_DETAILS` is ignored.
### Remotes and remote branches
In some git workflows, you must work with various remotes, for this reason, Bash-it can provide some useful information about your remotes and your remote branches, for example, the remote on you are working, or if your local branch is tracking a remote branch.
You can control this feature with the flag `SCM_GIT_SHOW_REMOTE_INFO` as follows:
Set `SCM_GIT_SHOW_REMOTE_INFO` to 'auto' (the default value) to activate it only when more than one remote is configured in the current repo:
* `export SCM_GIT_SHOW_REMOTE_INFO=auto`
Set `SCM_GIT_SHOW_REMOTE_INFO` to 'true' to always activate the feature:
* `export SCM_GIT_SHOW_REMOTE_INFO=true`
Set `SCM_GIT_SHOW_REMOTE_INFO` to 'false' to **disable the feature**:
* `export SCM_GIT_SHOW_REMOTE_INFO=false`
**NOTE:** If using `SCM_GIT_SHOW_MINIMAL_INFO=true`, then the value of `SCM_GIT_SHOW_REMOTE_INFO` is ignored.
### Untracked files
By default, the `git status` command shows information about *untracked* files.
This behavior can be controlled through command-line flags or git configuration files.
For big repositories, ignoring *untracked* files can make git faster.
Bash-it uses `git status` to gather the repo information it shows in the prompt, so in some circumstances, it can be useful to instruct Bash-it to ignore these files.
You can control this behavior with the flag `SCM_GIT_IGNORE_UNTRACKED`:
Set `SCM_GIT_IGNORE_UNTRACKED` to 'false' (the default value) to get information about *untracked* files:
* `export SCM_GIT_IGNORE_UNTRACKED=false`
Set `SCM_GIT_IGNORE_UNTRACKED` to 'true' to **ignore***untracked* files:
* `export SCM_GIT_IGNORE_UNTRACKED=true`
Also, with this flag to false, Bash-it will not show the repository as dirty when the repo has *untracked* files, and will not display the count of *untracked* files.
**NOTE:** If you set in git configuration file the option to ignore *untracked* files, this flag has no effect, and Bash-it will ignore *untracked* files always.
### Stash item count
When `SCM_GIT_SHOW_DETAILS` is enabled, you can get the count of *stashed* items. This feature can be useful when a user has a lot of stash items.
This feature is controlled through the flag `SCM_GIT_SHOW_STASH_INFO` as follows:
Set `SCM_GIT_SHOW_STASH_INFO` to 'true' (the default value) to **show** the count of stashed items:
* `export SCM_GIT_SHOW_STASH_INFO=true`
Set `SCM_GIT_SHOW_STASH_INFO` to 'false' to **don't show** it:
* `export SCM_GIT_SHOW_STASH_INFO=false`
### Ahead/Behind Count
When displaying information regarding whether or not the local branch is ahead or behind its remote counterpart, you can opt to display the number of commits ahead/behind.
This is useful if you only care whether or not you are ahead or behind and do not care how far ahead/behind you are.
Set `SCM_GIT_SHOW_COMMIT_COUNT` to 'true' (the default value) to **show** the count of commits ahead/behind:
* `export SCM_GIT_SHOW_COMMIT_COUNT=true`
Set `SCM_GIT_SHOW_COMMIT_COUNT` to 'false' to **don't show** it:
* `export SCM_GIT_SHOW_COMMIT_COUNT=false`
### Git user
In some environments, it is useful to know the value of the current git user, which is used to mark all new commits.
For example, any organization that uses the practice of pair programming will typically author each commit with [combined names of the two authors](https://github.com/pivotal/git_scripts).
When another pair uses the same pairing station, the authors are changed at the beginning of the session.
To get up and running with this technique, run `gem install pivotal_git_scripts`, and then edit your `~/.pairs` file, according to the specification on the [gem's homepage](https://github.com/pivotal/git_scripts).
After that, you should be able to run `git pair kg as` to set the author to, eg. "Konstantin Gredeskoul and Alex Saxby", assuming they've been added to the `~/.pairs` file.
Please see gem's documentation for more information.
To enable the display of the current pair in the prompt, you must set `SCM_GIT_SHOW_CURRENT_USER` to `true`.
Once set, the `SCM_CURRENT_USER` variable will be automatically populated with the initials of the git author(s).
It will also be included in the default git prompt.
Even if you do not have `git pair` installed, as long as your `user.name` is set, your initials will be computed from your name and shown in the prompt.
You can control the prefix and the suffix of this component using the two variables:
* `export SCM_THEME_CURRENT_USER_PREFFIX=' ☺︎ '`
And
* `export SCM_THEME_CURRENT_USER_SUFFIX=' ☺︎ '`
**NOTE:** If using `SCM_GIT_SHOW_MINIMAL_INFO=true`, then the value of `SCM_GIT_SHOW_CURRENT_USER` is ignored.
### Git show minimal status info
To speed up the prompt while still getting minimal git status information displayed such as the value of `HEAD` and whether there are any dirty objects, you can set:
```
export SCM_GIT_SHOW_MINIMAL_INFO=true
```
### Ignore repo status
When working in repos with a large codebase, Bash-it can slow down your prompt when checking the repo status.
To avoid it, there is an option you can set via Git config to disable checking repo status in Bash-it.
To disable checking the status in the current repo:
```
$ git config --add bash-it.hide-status 1
```
But if you would like to disable it globally, and stop checking the status for all of your repos:
```
$ git config --global --add bash-it.hide-status 1
```
Setting this flag globally has the same effect as `SCM_CHECK=true`, but only for Git repos.
### Speed up git status calculations
As an alternative to ignoring repo status entirely, you can try out the `gitstatus` plugin.
This plugin speeds up all `git status` calculations by up to 10x times!
**NOTE**: You will need to clone `gitstatus` repo from [here](https://github.com/romkatv/gitstatus).
### Pass function renamed to passgen
The Bash-it `pass` function has been renamed to `passgen` in order to avoid a naming conflict with the [pass password manager](https://www.passwordstore.org/).
In order to minimize the impact on users of the legacy Bash-it `pass` function, Bash-it will create the alias `pass` that calls the new `passgen` function if the `pass` password manager command is not found on the `PATH` (default behavior).
This behavior can be overridden with the `BASH_IT_LEGACY_PASS` flag as follows:
Set `BASH_IT_LEGACY_PASS` to 'true' to force Bash-it to always **create** the `pass` alias to `passgen`:
* `export BASH_IT_LEGACY_PASS=true`
Unset `BASH_IT_LEGACY_PASS` to have Bash-it **return to default behavior**:
* `unset BASH_IT_LEGACY_PASS`
### Debugging
If you encounter problems with any part of Bash-it, run the following command:
```bash
bash-it doctor
```
This will reload your bash profile and print out logs of various parts in Bash-it.
Note that this command at default will print all logs, including debug logs.
You can call it like this:
```bash
bash-it doctor [errors/warnings/all]
```
In order to get wanted verbosity.
### Proxy Support
If you are working in a corporate environment where you have to go through a proxy server for internet access,
then you know how painful it is to configure the OS proxy variables in the shell,
especially if you are switching between environments, e.g. office (with proxy) and home (without proxy).
The Bash shell (and many shell tools) use the following variables to define the proxy to use:
* `HTTP_PROXY` (and `http_proxy`): Defines the proxy server for HTTP requests
* `HTTPS_PROXY` (and `https_proxy`): Defines the proxy server for HTTPS requests
* `ALL_PROXY` (and `all_proxy`): Used by some tools for the same purpose as above
* `NO_PROXY` (and `no_proxy`): Comma-separated list of hostnames that don't have to go through the proxy
Bash-it's `proxy` plugin allows to enable and disable these variables with a simple command.
To start using the `proxy` plugin, run the following:
```bash
bash-it enable plugin proxy
```
Bash-it also provides support for enabling/disabling proxy settings for various shell tools.
The following backends are currently supported (in addition to the shell's environment variables): Git, SVN, npm, ssh.
The `proxy` plugin changes the configuration files of these tools to enable or disable the proxy settings.
Bash-it uses the following variables to set the shell's proxy settings when you call `enable-proxy`.
These variables are best defined in a custom script in Bash-it's custom script folder (`$BASH_IT/custom`), e.g. `$BASH_IT/custom/proxy.env.bash`
* `BASH_IT_HTTP_PROXY` and `BASH_IT_HTTPS_PROXY`: Define the proxy URL to be used, e.g. 'http://localhost:1234'
* `BASH_IT_NO_PROXY`: A comma-separated list of proxy exclusions, e.g. `127.0.0.1,localhost`
Once you have defined these variables (and have run `reload` to load the changes), you can use the following commands to enable or disable the proxy settings in your current shell:
* `enable-proxy`: This sets the shell's proxy environment variables and configures proxy support in your SVN, npm, and SSH configuration files.
* `disable-proxy`: This unsets the shell's proxy environment variables and disables proxy support in your SVN, npm, and SSH configuration files.
There are many more proxy commands, e.g. for changing the local Git project's proxy settings.
Run `glossary proxy` to show the available proxy functions with a short description.
## Help out
We think everyone has their own custom scripts accumulated over time.
And so, following in the footsteps of oh-my-zsh, Bash-it is a framework for easily customizing your Bash shell.
Everyone's got a custom toolbox, so let's start making them even better, **as a community!**
Send us a pull request and we'll merge it as long as it looks good.
If you change an existing command, please give an explanation why.
That will help a lot when we merge your changes in.
Please take a look at the [Contribution Guidelines](CONTRIBUTING.md) before reporting a bug or providing a new feature.
options="help clean config dedupe deinstall delete dev develop docs erase featured home init install link linked links list ln lns login ls open outdated publish rebuild rebuild-module-cache remove rm search show star starred stars test uninstall unlink unpublish unstar update upgrade view"
available_things=$(for f in `compgen -G "${BASH_IT}/$subdirectory/available/*.bash"| sort -d`;
do
file_entity=$(basename $f)
typesetenabled_component=$(command ls "${BASH_IT}/$subdirectory/enabled/"{[0-9]*$BASH_IT_LOAD_PRIORITY_SEPARATOR$file_entity,$file_entity} 2>/dev/null | head -1)
typesetenabled_component_global=$(command ls "${BASH_IT}/enabled/"[0-9]*$BASH_IT_LOAD_PRIORITY_SEPARATOR$file_entity 2>/dev/null | head -1)
localcommands=(active config create env inspect ip kill ls mount provision regenerate-certs restart rm ssh scp start status stop upgrade url version help)