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).
* 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)`
The direnv bash hook already add a semicolon to the PROMPT_COMMAND and this
plugin will add another one if direnv is installed. This commit will check if
the PROMPT_COMMAND ends with semicolon to avoid have double ones.
The layout will have returned to the default, placing all bundled
apps onto the first screen of Launchpad, and third party apps onto
the secondary (and third, if applicable) screens
This commit fixes an issue with themes on OS X which are sometimes
left in a partially broken environment with missing dependencies.
When a `BASH_IT_THEME` is active on OS X and has a
dynamic `PROMPT_COMMAND` which is not exported, and such
`PROMPT_COMMAND` is backed by shell functions which are not
exported either, and at the same time the theme is not
OS-X-aware (regarding `update_terminal_cwd`), and the
user launches a (non-login) interactive subshell from
the OS X Terminal, a `command not found` appears on every
command invocation.
The issue is caused by a regression in PR #514, which attempts to
inject `update_terminal_cwd` into the prompt. As a side effect, it
also escalates the exportedness of `PROMPT_COMMAND` while the
theme-specific backing functions (which power the dynamic prompt)
remain unexported.
The subshell cannot recover from this partially broken environment
because unlike in Linux, Bash-it on OS X is not invoked for non-login
subshells. The dependencies remain broken which leads to the error.
The fix is to preserve `PROMPT_COMMAND`’s exportedness on OS X,
leaving the individual theme responsible for consistently
exporting either all or nothing of its environment.
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.
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.
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.
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.
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.
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.
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.
John D Pell
John D Pell
Truong Ma Phi
Enze Chi
Nils Winkler
Kai-Ming Guo
Claudia
cs-networks
Faro
Erich Smith
Eitan Adler
Mark Szymanski
Travis Swicegood