The update_terminal_cmd is interfering with the $? variable. Somehow it
is always 0.
```
caesium@Mac:~/Documents/projects/git/bash-it 0 >export
PROMPT_COMMAND="update_terminal_cwd;set_prompt"
caesium@Mac:~/Documents/projects/git/bash-it 0 >false
caesium@Mac:~/Documents/projects/git/bash-it 0 >true
caesium@Mac:~/Documents/projects/git/bash-it 0 >export
PROMPT_COMMAND="set_prompt;update_terminal_cwd"
caesium@Mac:~/Documents/projects/git/bash-it 0 >false
caesium@Mac:~/Documents/projects/git/bash-it 1 >true
caesium@Mac:~/Documents/projects/git/bash-it 0 >
```
After the fix it is working properly.
The `~` caused docker commands to error with the following:
```
$ docker images
Could not read CA certificate "~/.docker/machine/machines/dev/ca.pem"
```
Switching to $HOME fixes the issue
This plugin adds completion to aliases, just as with their regular
commands. Example:
* Completion works for `git checkout <TAB>`, which shows available
branches.
* You have an alias like `alias gco="git checkout"`
* The plugin adds support for `gco <TAB>`, which will also show the
available branches.
Reference: http://superuser.com/a/437508/119764
Some functions were specific to OS X, but were defined in the `base` plugin. I have moved them to the `osx` plugin:
* pman
* pcurl
* pri
As for `pcurl`, the `osx` plugin already had an existing `prevcurl` function, which was doing the same thing. I've aliased `pcurl` to simply call `prevcurl` to avoid breaking existing installations.
As far as I know the `open -fa $PREVIEW` thing only works on OS X, which means that these functions have only worked on OS X anyway.
A set of functions to simplify listing OS X Time Machine backups, and
deleting old ones. Pulled from various script solutions found on Stack
Overflow, adapted to the Bash-it framework.
The functions allow to show which backups can be found on the connected
Time Machine volume. The 'delete' function allows to safely remove all
backups except for the latest one - this can be used to free up space on
the Time Machine volume. The 'delete' function uses functionality of the
OS to safely remove the old backups, no information is lost.
The 'delete' function will only ask for the password once, then keep the credentials.
Source: http://stackoverflow.com/a/30547074/1228454
When pygmentize is not installed, the functions less/cat are not
defined, the native commands will be used instead. Also removed the
error message that was shown when the command was not found.
Using `command -v` instead of `which` to check for the existence of the
executable - this works better as it does not print an error message if
the executable is not found.
This will allow to open new terminal tabs in the same directory as the
current terminal. Uses the fact that plugins are loaded after the
selected theme. Themes often manipulate the $PROMPT_COMMAND variable.
Implementation inspired by the pathmunge function.
The previous version was printing an error when the battery percentage
was in the single digits, e.g. "7.04%". The code cuts returns the first
two digits, which in the case of "7.04%" are "7.". Any code that tries
to use that, e.g. the powerline-multiline theme will fail with an error.
This change corrects that by zero padding single digits, i.e. "07.04%"
instead of "7.04%".
These settings shouldn't be in the profile template, as they only make sense when used with nginx.
If you're using nginx, you can enable the nginx plugin.
The vagrant.plugin.bash file only defined a completion function, nothing
more. The vagrant.completion.bash file has a more recent completion
function for vagrant. We don't need both, and the completion in the
plugin file was in the wrong location in the first place.
If you had multiple terminal windows open, there was a chance that the command was sent to another window (the one with index 1). Using index 0 will execute it in the currently visible window.
working in concert with one another.
Features added:
- Added a pyenv-virtualenv plugin which creates virtual environments
using the current pyenv python version
- `cd` into a directory that has a virtual environment already created
and autoenv will automatically activate that environment
- Current virtual environment is displayed in command prompt
new tab. If you use `export HISTIGNORE=' *'` in your shell, this will
ensure that commands starting with a space will not be included in the
history. Since the command sent to the new tab by the `tab` command
probably shouldn't show up in the history, I added a leading space
character.
* chruby.bash loads chruby
* chruby-auto.bash loads chruby and enables auto-switching
* add chruby_version_prompt() function for displaying ruby version
* inspired by https://gist.github.com/rssvihla/6153455
it isn't safe to assume that symlinks created in the enabled/* dirs will
be symlinks later...
some users use tools like Dropbox to sync their files across systems,
and these may transform symlinks into regular files. explicitly
checking for symlinks with tests like [ -h $file ] will break on these
systems. these tests have been replaced with [ -e $file ] instead.
this replaces the naive implementation that called glossary() on each
group, and is an order of magnitude faster.
fix grouping in javascript.plugin.bash
loading fasd clobbers z(), and results in a cryptic syntax error
message, since 'z' is already an alias when z.plugin.bash is being
sourced.
this conditional detects this situation and returns early.
add about-plugin metadata
chmod -x plugins
cleanup filenames to standardize on x.plugin.bash format
only plugin files intended to be executable from the command line should
contain a shebang line, and should be a+x.
overrides may now be specified for any of these defaults:
TODO_DIR=$BASH_IT/custom # change if you want todo.txt and friends
# to live somewhere else
TODOTXT_DEFAULT_ACTION=ls # change if you want a different action,
# like 'lsp' or 'lsprj'
TODO_SRC_DIR=
$BASH_IT/plugins/available/todo # for custom installs with plugins
Since it is referenced in the default .bash_profile and in aliases and
themes, why not make it an official plugin?
This creates a 'todo/' directory in /plugins/available, and installs
todo.sh and friends there. Tab completion and the 't' alias should work
out of the box.
Note: it was also necessary to modify .gitignore to ignore the files
todo.sh generates in custom/.
cite about-plugin metadata. This could be retrieved later, say by an
install script or other helper function, with:
cat ~/.bash_it/plugins/enabled/base.plugin.bash | metafor about-plugin
In this way, summaries of each plugin may be provided to give newcomers
(like me!) an overview.
also, rewrote plugins-help(), which didn't work very well on my system.
It now dynamically queries composure metadata.
The [fasd](https://github.com/clvv/fasd) project replaces the current
z() functionality, and generalizes it for all files and directories.
It provides a 'z' alias which works like z() does today, but faster, as
well as 'f' for selecting files, and 'd' for selecting directories, all
based on 'frecency' with Bayesian inference calculations. It is also
trivial to set up a 'v' alias to edit frecently used files.
Seriously, two points just for using Bayes' theorem.
I've sourced this as a plugin, and made a minor modification to @clvv's
0.5.4 file to bootstrap the initialization process without installing
fasd outside of Bash_it, or modifying the PATH.
This doesn't fully install fasd on a system (for instance, the man page
is not installed).
Using this as a plugin will clobber the z plugin.
This also installs a PROMPT_COMMAND hook. I don't have a complex setup,
but it is possible this may not play nice with other PROMPT_COMMAND
hooks if they are set. It seems to work well on my box.
As an aside, it appears that z.bash is out-of-date compared with @rupa's
latest code.
This allows users to disable a plugin without completely removing it.
Instead, they simply remove the `plugins/enabled/*.bash` file for the
plugin they want to disable. This continues the concept of "everything
on" while providing greater flexibility to future users.
It might be a good idea to allow turning these off by default in the
future and allowing not only the `plugins/enabled/*.bash` files but also
an array of `<plugin_name>` values that would search for
`plugins/available/<plugin_name>.plugin.bash` to enable them. That
method would make it easier for people custom tune their plugins from
within their `.bash_profile` script.