Most of the time, people use programs like tr(1) and wc(1) when they're
woefully unnecessary, serving only to make their programs inefficient
and bloated. BASH itself can deal with most of these tasks with
absolute ease. This is one such situation.
In:
```bash
if [[ -n "$(_git-status | tail -n1)" ]]; then
```
It seems pointless using tail(1); it does nothing here, unless I'm
missing something. Also, quotes aren't needed, because word-splitting
doesn't apply when variables are expanded in `[[`.
```bash
if [[ -n $(_git-status) ]]; then
```
The quoting thing is all over the code, but not a huge deal, as it's
just superficial. Variable word-splitting doesn't apply also during
the WORD in the case statement, and the VALUE in shell variable
assignment.
Personally, I would use `[`, since none of the `[[` features are being
used here, so it seems wasteful. In the BASH (4.4) source code,
assuming I'm looking at it correctly, `[[` is over 800 lines, yet `[`
(or `test`) is not even 200; that's part of the reason I prefer `[` and
use `[[` when it's actually needed. It's also not a huge deal though, -
as this is going to be incredibly fast either way, but thought I'd
mention it.
This sort of test:
```sh
if CONDITION; then
if CONDITION; then
LIST
fi
fi
```
The above is typically unnecessary, as the two conditions can be
combined to avoid pointless nesting.
Regarding the optimization: it's very minor, but there was an
unnecessary use of a subshell (command substitution) in testing this:
```
git rev-parse --is-inside-work-tree
```
This has been addressed, and instead of STDERR going to '/dev/null', -
now both STDOUT and STDERR do.
Although I'm pointing out this in just one instance, this sort of stuff
appears to be all over the code in this project, unfortunately.
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
`tr 'A-Z' 'a-z'` will only convert non-accented characters. Switching to
`[:upper:]` and `[:lower:]` adds support for accents.
See https://github.com/koalaman/shellcheck/wiki/SC2018
Additionally, printf's character splitting does not support accented
characters, so output isn't as expected. Using bash's variable expansion
syntax instead will correctly get the full accented character.