* 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
bash-it takes rather a while to startup, around 0.5 seconds on my
laptop. After a bit of timing it appears the majority of the time is
spent in themes/colors.theme.bash. The reason for that is the fancy
abstraction layers that use $(). For example, consider this code:
red="$(color reset red)"
It will go through 9 forkexecs to evaluate:
red="$(color reset red)"
"$(__color_parse make_ansi reset red)"
"$(__make_ansi reset red)"
"\[\e[$(__reset red)m\]"
"\[\e[0;$(__red)m\]"
"\[\e[0;$(__color red)m\]"
"\[\e[0;$(__color_normal_fg $(__color_red))m\]"
"\[\e[0;$(__color_normal_fg 1)m\]"
"\[\e[0;31m\]"
With all the variables in colors.theme.bash, this adds up to hundreds of
forks:
$ strace -f bash ./colors.theme.bash 2>&1 | grep clone | wc -l
649
The solution is to replace the function with its result:
-red="$(color reset red)"
+red='\[\e[0;31m\]'
This is safe, since colors.theme.bash never calls external functions or
takes any input. So, its result can be safely hard-coded.
This improves startup time dramatically. Try adding "time" to your .bashrc:
# Load Bash It
time source $BASH_IT/bash_it.sh
before:
real 0m0.462s
user 0m0.100s
sys 0m0.399s
after:
real 0m0.150s
user 0m0.091s
sys 0m0.064s
When using `set -x` with a `$PS4` variable which calls a external
command (e.g. `PS4='+ $(true)'`) the color functions end in a infite
loop.
The solution is `shift` the arguments unconditionally in the color
funtions.
This fixes#546
John D Pell
phreakocious
Daijiro Wachi
Brian Malehorn
Hector Rivas Gandara
Eitan Adler
Beren Minor
Travis Swicegood
JFSIII
Robert R Evans