Adding `node` prompt that does not depend on `nvm` and will work with other version managers as well.
There are now alternative version managers available, such as a much more streamlined [volta.sh](https://volta.sh). It feels like a deja-vu of `rvm` to `rbenv` switch, all over again.
Regardless, we should be able to show the current `node` version whether you are using NVM, VOLTA or a hot potato.
I decided not to add dedicated PREFIX variables for now, but it can be done later.
We still check if `nvm` prompt returns something first because the `declare` check is practically free, and if it returns something — we use it. Only if the output of NVM is blank do we use the new function to grab the version of NodeJS.
There is a caveat — if `node` is installed with the OS, eg `/usr/bin/node` the new function will now pick up the version of that "system" node and show it. Therefore "system" node version will now be visible in the prompt of those who added `node` component to their prompt. Personally, I believe this is the correct behavior, because why should we hide the system node version if that's what's available and in the PATH? We shouldn't. In fact, I think it's rather confusing that previously we wouldn't show the system node version at all.
Tested locally on OS-X/bash:
* with/without NVM
* with/without VOLTA
* with/without system node
hexdump by default will replace any repeated groups with an asterisk and
a newline, which breaks prompts. This can be disabled with the `-v`
flag. For example:
```
printf 'aac' | hexdump -e '1/1 "%02x"'
61*
63
printf 'abc' | hexdump -e '1/1 "%02x"'
616263
printf 'aac' | hexdump -ve '1/1 "%02x"'
616163
```
When spawning a new bash session when entering a virtual environment
the VIRTUAL_ENV is overwritten by this line.
However not having this line does not affect the bin/activate script.
Stop as soon as "svn status" shows a change, not needed to walk through
all the changes in the whole repository. For my large repository this is
about twice as fast.
Extract just the information we need from "svn info"
When current-context does not exist or is unset in $KUBECONFIG, kubectl
is throwing a message to stderr "error: current-context is not set".
Ignore it.
In order to make `git_prompt_vars` run faster
As a user with slow `git stash list`
I want to be able to optionally disable running `git stash list` when
`git_prompt_vars` is executed
This patch adds very simple support for the Perforce SCM:
https://www.perforce.com/
Although perforce is proprietary software, it's somewhat prevalent in enterprise
companies. This patch looks to provide some basic bash_it functionality that
I've come to love for git. I base everything off of two perforce commands:
$ p4 set
This command does not require a connection the perforce server, it simply tells
us if a directory is managed by the Perforce SCM or not. In addition the
command:
$ p4 opened
is used to provide the list of pending changes in the client and the number of
opened files in the client. The `p4 opened` command requires a connection to the
perforce server, hence it's run under a `timeout` command. The "p4 opened"
processing into it's own bash file that now has to be sourced at the top-level
bash-it.sh. Since the processing in simple the newly added: _p4-opened-counts
function returns a number of things that are not currently used, but since I had
awk open and doing the processing, I've chosen to include them in the output
anyway.
Testing:
- Tested with the powerline-multiline theme in a few perforce based
workspaces/clients
- Ran:
❯ shellcheck themes/p4helpers.theme.bash
and fixed all the errors
- Ran the test suite:
❯ test/run
[...]
182 tests, 0 failures, 1 skipped
Konstantin Gredeskoul
John D Pell
Noah Gorny
ofir shtrull
Oliver Ruben Albertini
BarbUk
Marcos Pereira
Markus Krause
Nils Winkler
buhl
salex
Eduardo Bellido Bellido
Eduardo Bart
Zhao Li
Martin Ankerl
Levent Yalcin
Zhao Li
Szymon Szypulski
Travis Swicegood
Jeremy Mathevet
sharils
Gabriel Smadi
Piotr Rogoza
Ethan Edwards
Piotr Rogoża
Shashank Bharadwaj