When running 'zsh' on ITerm2, I got that weird messages.

Note that I hit Enter a few times just to see if message disappears, but it's still there.

I`m using OSX (10.11.1) El Captan.

Using ConEmu and Git Bash (MsysGit), make install fails on copying .bash_prompt. I'm not sure exactly what caused it, but simply running touch ~/.bash_prompt and then re-running make fixed the problem.

$ make install
# Copying .bash_prompt to ~/.bash_prompt
cp -f .bash_prompt ~/.bash_prompt
cp: cannot create regular file `~/.bash_prompt': No such file or directory
Makefile:6: recipe for target 'install' failed
mingw32-make: *** [install] Error 1
$ touch ~/.bash_prompt
$ make install
# Copying .bash_prompt to ~/.bash_prompt
cp -f .bash_prompt ~/.bash_prompt
./install.bash
# Adding ~/.bash_prompt to ~/.bashrc
# twolfson/sexy-bash-prompt installation complete!
exit 0

In #80 we discussed developing a system of opt-in flags for extensions to the prompt, which would allow users to enable features like exit code reporting or long-running process timers.

Discuss implementation details here. How should we do this?

I've noticed that sexy-bash-prompt causes the terminal to wait for some time when visiting a git repository initially. After about ~20 seconds, control is given back to the user. Subsequent visits to that same directory throughout the day seem to be instantanteous. If you don't visit the directory for a prolonged time (say 12 hours), the slowness still occurs.

I've been trying to do some testing, but since cd isn't really a executable command, I can't simply chain two date commands in the same line.

Below is a simple test that I ran (see image):

I've noticed that if I copy a repository that I haven't visited in a while, the same slow behavior occurs when I cd into that copied directory. I'm thinking it has something to do with caching, but I'm not too sure.

During the color override release, we had a regression in non-256 color terminals for their prompt_git_status_color. The setting disappeared during to refactoring (it was renamed to prompt_symbol_color.

As with all regressions, we should write a regression test against this (and probablhy all colors) to prevent future ones from occurring.

For semantic/installation consistency, rename .bashrc to .bash_prompt. This is currently being blocked by a branch for DRYing up code.

We call git rev-parse with is_on_git() and then call it again with get_git_progress(). These functions can be combined to avoid duplicating the slow (possibly very slow) work of searching back up the tree.

I background things a lot. Especially with the editor. Then I come back to the window in tmux and forgot if I have the job backgrounded and type fg to check, which wastes time.

I thought the prompt could report this for me. So I threw something together:

https://github.com/rpdelaney/sexy-bash-prompt/tree/jobs

I guess this might be scope creep. I'm happy to leave it in my own fork.

But it's easy and useful. Shell builtins mostly. What do you think?

Since all of the functions in the script are being exported into the environment, maybe we should reconsider their generic names since they can be invoked from the interactive shell.

For example, instead of is_branch1_behind_branch2, call it prompt_is_branch1_behind_branch2. is_ or get_ are too generic for something so specific that's being exported into the ecosystem, and have a chance of interfering with autocompletion for some other commands (as in my case).

Prefixing the exported functions with prompt or promptfn would be an easy and sensible solution.

Hi
First thanks for the awesome project

I work with many repositories and have to commit the code as different users.
Quite often if I forget to set specific

git config user.name "name"
git config user.email "email"

I make the commit under my global username and email. Then later I have to fix the commits rewrite github history etc.
For me seeing under which username and email is currently set would be very useful.
I'm wandering if others would also like such functionality.
It could be optional, and disabled by default as most people would like their prompt to be as short as possible.

Using Ubuntu I had to modify .profile to remove these lines:
echo "# Trigger ~/.bashrc commands" >> "$PROFILE_SCRIPT_FULL"
echo ". ~/.bashrc" >> "$PROFILE_SCRIPT_FULL"

bashrc was already called from .profile and this was causing an error. As a result after running this script and logging out of unity, I could not log back into unity until this was removed.

Hope this makes sense, thanks for the great prompt.

MacOSX doesn't use ~/.bashrc. Instead it uses the first file it finds out of a specific list, shown here: http://apple.stackexchange.com/questions/12993/why-doesnt-bashrc-run-automatically#comment13715_13019

To make your script work locally on MacOSX I took the hook you added in bashrc and added it to .bash_profile instead. It sounds though, like you might need to make sure you put it in the right one (since the creation of .bash_profile would stomp on .profile)

I'm revisiting my personal support system and deciding to move away from Flattr. Their UI redesign made things much harder, less transparent, and we have received 0 donations. I have seen Open Collective on quite a few prominent repos recently:

https://github.com/mochajs/mocha/tree/v3.1.2#backers

https://github.com/gulpjs/gulp/tree/0469094bb8c4c54e5bb8b2cf5994dd72fa8db713#backers

They seem like something good to try out. I'm going to get the application process started

/cc @rpdelaney

We wrote a installation test script. Unfortunately, Travis CI hangs while running it. Look into why this is and how to fix it.

This would be great for testing multiple environments (e.g. .bashrc auto-invoked, .bash_profile update required, .bash_login exists).

TODO: Might want to make a better demo script which copies folders, moves to them, and runs.

TODO: Might want to show clean directory

So I'm not sure if this is intentional or not, but if you have a git repo that either:

• Has no remote branches
• Has remote branches but no origin branch

The not pushed triangle always displays.

On one of my repos I have set up two remotes (redundancy). Even after pushing to both remotes, the prompt indicates 'unpushed' status. I haven't had time to look into this yet with a clean test case, so it may just be some quirk on my repo.

Greetings, @twolfson, et al.! :-)

I'm visiting from gratipay/project-review#107, where we're discussing whether sexy-bash-prompt is a project we want to accept as a Team on Gratipay. We're stumbling on the name, to be honest. "Sexy," while obviously not an egregiously sexist term, does seem to contribute somewhat to a sexualized tech culture that is generally alienating to women—something we at Gratipay would prefer to avoid endorsing.

@twolfson commented over there:

To provide info from my perspective, the initial script wasn't written by me but I wound up formalizing it into a repo:

https://gist.github.com/gf3/306785/a35d28b6bdd0f7c54318cce510738438f04dabaa

That's the "Forked from a gist by gf3." on the README. I was hesitant about keeping the name (for similar reasons as listed above) but I kept it consistent for easier discovery.

I think at this point it might be a large blow to the awareness of the repo since this isn't a copy change but a change to the repository's handle =/

Fair enough. As mentioned, GitHub does offer repo redirects now, so that in itself needn't be a worry. Furthermore, the original script from Steve Losh is called "Extravagant Zsh Prompt," so if you rename this project to "Extravagant Bash Prompt," you'll in fact be more closely aligning yourselves with Steve's original project, which could improve discovery. ;-)

@twolfson, et al. Waddya think? Are you willing to rename to "Extravagant Bash Prompt"? :-)

Lines 6 to 9 set TERM to "xterm-256color". This has unintended consequences when working within tmux since TERM needs to be "screen-256color" for ncurses applications to function correctly inside tmux.

I have a branch to smarten this up a bit. I will submit a pull request if you like.

However, in my view this is a hack and it is a bad idea in general to manipulate the value of TERM in .bash_prompt. Determining and setting the correct TERM value that is appropriate to the environment is simply not a task of the .bash_prompt. Rather, .bash_prompt should read TERM and set PS1 accordingly, and users should be expected to set their own TERM correctly in .bashrc.

I wanted to add the exit status to the prompt, but it always returns zero, even when it shouldn't.
I tested it with rm x which returns 1 since x doesn't exist.

Is it possible to also show if files are on the stash or not?

Installation fails with

$ make install
# Copying .bash_prompt to ~/.bash_prompt
cp -f ".bash_prompt" "/home/chris/.bash_prompt"
./install.bash
./install.bash: line 2: $'\r': command not found
./install.bash: line 4: syntax error near unexpected token `$'{\r''
'/install.bash: line 4: `ps1_is_installed () {
make: *** [install] Error 2

This is a line-ending issue.
Doing sed -i 's/\r$//' sed -i 's/\r$//' install.bash before make install
gets one step further, but then

$ make install
# Copying .bash_prompt to ~/.bash_prompt
cp -f ".bash_prompt" "/home/chris/.bash_prompt"
./install.bash
: command not found
bash: /home/chris/.bash_prompt: line 100: syntax error near unexpected token `$'{\r''
'ash: /home/chris/.bash_prompt: line 100: `function sexy_bash_prompt_get_git_branch() {
# Adding ~/.bash_prompt to ~/.bashrc
: command not found
bash: /home/chris/.bash_prompt: line 100: syntax error near unexpected token `$'{\r''
'ash: /home/chris/.bash_prompt: line 100: `function sexy_bash_prompt_get_git_branch() {
: command not found
bash: /home/chris/.bash_prompt: line 100: syntax error near unexpected token `$'{\r''
'ash: /home/chris/.bash_prompt: line 100: `function sexy_bash_prompt_get_git_branch() {
# We cannot confirm that sexy-bash-prompt has installed properly
# Please open a new terminal window to confirm

# If it has not, please run the following code:
echo ". ~/.bashrc" >> "/home/chris/.profile"
make: *** [install] Error 1

So another sed -i 's/\r$//' ~/.bash_prompt to resolve this.

It did seem to update the .bashrc correctly (added this at the end)

# Run twolfson/sexy-bash-prompt
. ~/.bash_prompt

however, mine was added multiple times (each times make install failed I guess).

So, this workaround is fine, but it would be nice to figure out how to fix this properly. I'm a bit as to where in the process invalid line breaks get introduced.

Is possible to not change the PS1 output of the shell?
in my case is:
mte90@siduction:~$
but with that became
#

Per #bash on freenode and Greg's wiki, "By convention, environment variables (PATH, EDITOR, SHELL, ...) and internal shell variables (BASH_VERSION, RANDOM, ...) are fully capitalized. All other variable names should contain at least one lowercase letter. Since variable names are case-sensitive, this convention avoids accidentally overriding environmental and internal variables."

As a prelude to a patch addressing Issue #19, would you accept a pull request setting the local variables to lower case? In addition to eliminating the (admittedly low) risk of sexy-bash-prompt over-writing environment variables, it would facilitate support of color overrides through the environment (making clear which variables are dimensioned locally and which variables are imported).

I'm getting a test failure on master right now:

ryan at mothership in ~/src/shell/sexy-bash-prompt on master
$ ./test/run.sh
# ERRORS OCCURRED. STDERR OUTPUT:
`sexy_bash_prompt_get_git_status` !== "⬡" on an unpushed and unpulled branch with a tracked non-origin remote Expected untracked unpushed-unpulled to have no tracked origin but it did not

During the same discovery as #4, we are not listing the proper information. However, this has not yet been patched. We know that git status lists out the branch name to be but are still exploring commands that return the appropriate value.

todd at Euclid in ~/github/tmp-git-init2 on (no branch)△
$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

When you ssh into a box, if you try to clear in the term it gives me:
$ clear
'gnome-256color': unknown terminal type.

I installed the prompt using the one-line installer. The installation worked fine, but when I tried opening vim later today, I got the following error:

Error detected while processing /Users/lexiross/.vimrc:
line  125:
E484: Can't open file /usr/local/share/vim/syntax/syntax.vim

Indeed, the syntax file is missing (line 125 of my vimrc is syntax on). I'm not 100% sure this is the cause, but I haven't changed my vimrc today and this is the only thing I've installed today. Do you have any idea why this might be happening?

Do we want one?

https://travis-ci.org/twolfson/sexy-bash-prompt/builds/9599241 failed. Look into why and fix it.

As discovered during research for the remaining in progress actions, git am and git rebase can walk through multiple commits. During each pause, there are files that list out the current step and the total amount of commits (e.g. step: 1, total: 2).

Should we display this information inside of the [rebase]/[am] notice?

todd at Euclid in ~/github/sexy-bash-prompt on dev/add.remaining.in.progress [rebase 1/20]
$ 

/cc @rpdelaney

I know it's an odd request for a git display, but it would be handy if the prompt included the system time in its' output as an option.

I can take a look at the source if needed, haven't had a chance to look at the code's source yet.

Anyone else think this would be useful?

Inside of #18, there was a conditional color change based on if the user was root/not.

It is a good idea but a bit of a one-off. I have had a similar set up for production.

Node Knockout setup

We should allow for overriding bash prompt colors via environment variables.

As requested, I'm opening a new issue from #5.

I've installed this script following the "One Line Install" instruction. When inside a git repository, it show 'no-branch', despite git status saying otherwise.

Output:

bfd at uaiti-omni110-2 in ~/ead on (no branch)△
$ git status
# On branch dev
nothing to commit (working directory clean)

Specs: Ubuntu 12.04LTS x64, Git version 1.7.9.5

Output of a freshly cloned repo make test (My system's language is Portuguese_BR):

# Cleaning up test files
rm test.stderr
rm: não foi possível remover “test.stderr”: Arquivo ou diretório não encontrado
make: [clean] Erro 1 (ignorado)
# Running all tests
./test/run.sh
# ERRORS OCCURRED. STDERR OUTPUT:
`get_git_branch` !== `master` on a `master` branch `get_git_branch` !== `dev/test` on `dev/test` branch `get_git_branch` !== `master` in a `git-init` directory `get_git_status` !== "" on a clean and synced branch `get_git_status` !== "*" on a dirty branch `get_git_status` !== "▽" on an unpulled branch `get_git_status` !== "▼" on a dirty unpulled branch `get_git_status` !== "⬡" on an unpushed and unpulled branch `get_git_status` !== "⬢" on a dirty, unpushed, and unpulled branch
make: ** [test] Erro 1

As unveiled in #8, there was a problem specific to the version of git provided by apt-get. Unfortunately, Travis-CI does not have an option at first glance.

One option might be Vagrantfiles or set of Dockerfiles, each configured with a different version of git.

Another is a more complex test script which builds and runs different versions of git.

Contemplate this problem more and pick a solution.

Hey, Todd.
Could you give directions to uninstall as well?
Thanks, mate.

At 187d2be, we were returning a false negative that a directory with git init is not on git. In 0.10.0, we patched this but have yet to write a test for it. Write a test for it.

There's a patch being considered here: https://public-inbox.org/git/[email protected]/t/#u

When called with --show-current, git branch will print the current
branch name and terminate. Only the actual name gets printed,
without refs/heads. In detached HEAD state, nothing is output.

However, as the threaded discussion shows, the implementation of this switch (and its intended use for scripting / machine parsing) is controversial. I don't know if it will be accepted or not.

Regardless, if it is accepted, do we want to use it anyway? Some time would pass before the new git version would be distributed widely enough.

In #80 we will work out how to support opt-in switches for extension. Exit code reporting is planned. For now we can discuss here what it should look like.

I've seen this feature in a few different shell prompts over the years. There are different ways of doing it. A couple things we could try, off the top:

1. A special STATUS_SUCCESS and STATUS_FAILED color that modifies an existing token (like the prompt character [$])
2. The same colors that modify a new token, also user-configurable

set -x is a familiar shell option for debugging. Usually, I like to set it from the command-line before running a script to debug, as is common practice. But this causes lots of unwanted debugging output from sexy-bash-prompt because the functions it invokes also return debugging output.

Would it be reasonable to add a handler to each function that checks for this flag, disables it, and then restores it before exit? I could submit a pull request to that effect.

OS: 3.2.0-29-generic #46-Ubuntu
Terminal: Putty/SuperPutty

I encountered a scenario when the current set of git symbols are incomprehensible/inaccurate. Inside of a getty session (ctrl+alt+f1 on a Linux machine). It made me realize we should add some form of detection for support (not sure if possible) and allow for overriding.

get_git_branch is overly simple by its replacement of heads/ref/. We should make it as wise as git symbolic-ref --short. Here are some thoughts:

Re-read shorten_unambiguous_ref from git/git.

I suspect the logic goes:

1. Remove one prefix/
2. Lookup the remaining ref
3. If the ref has 2 matches, use the previous version
4. Otherwise, if there are no / left, use the current version
5. Otherwise, go to (1)

Names have been changed to protect the innocent.

ryan.delaney at M-6496 in ~/src/
$ git clone [email protected]:org/repo.git 
Cloning into 'repo'...
remote: Enumerating objects: 544, done.
remote: Counting objects: 100% (544/544), done.                                                                                                                                                                                 
remote: Compressing objects: 100% (197/197), done.
remote: Total 453877 (delta 452), reused 364 (delta 344), pack-reused 453333                                                                                                                                                    
Receiving objects: 100% (453877/453877), 356.36 MiB | 4.65 MiB/s, done.
Resolving deltas: 100% (340993/340993), done.
Checking out files: 100% (10666/10666), done. 
ryan.delaney at M-6496 in ~/src
$ cd repo
ryan.delaney at M-6496 in ~/src/repo on master△
$ git status                                                                               
On branch master                                                           
Your branch is up to date with 'origin/master'.                       
                                                                                                       
nothing to commit, working tree clean  
ryan.delaney at M-6496 in ~/src/repo on master△
$ git push --dry-run
Everything up-to-date
ryan.delaney at M-6496 in ~/src/repo on master△
$

I don't have a lot of time to troubleshoot this right now but I wanted to create this issue at least so I don't forget.

I'm not 100% sure I'm using the most up to date version on this machine so here's my ~/.bash_prompt for later comparison: http://ix.io/1xUn

@twolfson If you have ideas for stuff I should look at let me know. I'll look into this later regardless.

I`m having this error when trying to run the one line install on my OSX 10.10.2 (Yosemite). I googled a lot but can't find any successful results. Here's the log:

  remote: Counting objects: 328, done.
  remote: Compressing objects: 100% (208/208), done.
  remote: Total 328 (delta 31), reused 307 (delta 30) 
  Receiving objects: 100% (328/328), 120.38 KiB | 0 bytes/s, done.
  Resolving deltas: 100% (31/31), done.
  Checking connectivity... done.
  # Copying .bash_prompt to ~/.bash_prompt
  cp -f .bash_prompt ~/.bash_prompt
  ./install.bash
  # Adding ~/.bash_prompt to ~/.bashrc
  FATAL: Profile script not found.
  make: *** [install] Error 1

...because $TMP should work on Linux, Mac and Windows :)

demo.sh, install.sh, symlink.sh, test.sh, test/utils/*.sh should all be relocated into a Makefile

I'm not yet sure how to handle incomplete merges better, but the default behavior (rendering as if clean) seems wrong. Maybe another unicode character would be better, or just an asterisk to suggest that the branch still contains uncommitted changes?

One of these symbols could be appropriate. Examples with unicode character short descriptions (in rough order of my preferences):

branch⑁ ocr chair
branch⑃ ocr inverted fork
branch⨝ set-theoretical join
branch⧉ two joined squares
branch⫓ subset above superset
branch≟ questioned equal to
branch≈ almost equal to

What do you think? Would you like a pull request?

I'm trying to use the sexy prompt inside a Docker container, but the icons display rather weird:

$ . ~/.bash_prompt 
<user>@3a4ffe9e19de:~/git/project on master���  

Note that I've tweaked the first part of the prompt a bit, but the last parts should be unchanged. When I ssh into the host machine it displays just fine (and it uses the exact same PS1). I'm running XFCE4 Terminal inside the Docker image.

Any thoughts what might be wrong?