Both my office and home computers have Git Bash for Windows from the very same source (Git for Windows, that came with TortoiseGit), but Git Bash's prompt differs on both machines:
on office computer I have /c/path (branch) all green (this is, how I would like it to have),
on home computer I have only path (no branch) and all white.
Up until now I was told, that this is PS1 variable, kept in ~/.bashrc file. However, on both machines, this files is missing (executing notepad ~/.bashrc opens up empty Notepad).
I'm lost here. If ~/.bashrc doesn't exists, then from where Git Bash "knows", that it should display current branch, in a green prompt? And why the same doesn't happen on second machine?
EDIT: I also tried to compare c:\Program Files\Git\etc\ folder contents for both machines and contents of Git Bash.vbs file. There identical on both computers so I even more have no idea, how it can be, that Git Bash's prompt differs on both computers (and how to fix this).
Several answers (like this, this and this) has suggested me, that I should look for .bash_profile and .bash_prompt files. Unfortunately, these two also are missing on both my computers.
Exactly what file decides about that under Windows 7? Where else should I look for, and what PS1 variable's value should be, to have current branch shown in green prompt on both machines?
Git on Windows almost always uses a bash shell. So, it's not Git setting the prompt as much as Bash does.
There are two ways to set prompts in Bash. One is the PS1 command which is fairly flexible, but is limited to a particular set of escape character sequences. Unfortunately, Git information isn't one of those escape sequences (although I suspect it'll come someday). You can use the second way to set the prompt by setting the PROMPT_COMMAND environment variable. If this is set, the $PROMPT_COMMAND is executed and used as the prompt instead of the PS1 environment variable.
When you install the standard Git with BASH, you're Git prompt is defined under the /etc/profile file. By the way, etc is a directory under where you've installed Git which is usually under %PROGRAMFILES% unless you changed it when you installed Git.
Under the /etc/profile script in line #156 in my version, you see the PS1 command being set and using $(__git_ps1) in $PS1 as a means of executing an external command in the prompt. (A third way I didn't mention previously).
The __git_ps1 is a shell function. You'll also notice a bit above (line #154 in my version) that /etc/git-completion.bash is being sourced in as well as /etc/git-prompt.sh. It's /etc/git-prompt.sh that defines the __git_ps1 function (Line #273 in my version) is defined. You'll notice that the __git_ps1 function pulls in several other functions defined in /etc/git-prompt.sh.
So, in a very Rube Goldberg manner, the Git prompt is being defined in /etc/profile via defining $PS1 which pulls in /etc/git-prompt.sh which defines a __git_ps1 function that pulls in the __git_ps1_show_upstream function and the __git_ps1_colorize_gitstring function. Then, $PS1 uses the $(...) string as part of pulling in the __git_ps1 function into PS1.
You can define your own $HOME/.bash_profile to override the way the prompt is set to define your own prompt. And, when you do that, you can also use the __git_ps1 Bash function in your own prompt.
Or, you can simply decide not to touch anything, and just back away very slowly. After all, you may have actual work to do.
On my Windows 10, __git_ps1 is defined in :
C:/Program Files/Git/etc/profile.d/git-prompt.sh.
I faced similar issue and realized that accidently I had added ${HOME} variable under environment/system variables(This PC) in my windows 10 64 bit pointing to my unixhome path. Once I removed it, the issue got fixed. My Git Bash prompt is back to how it used to look.
I would make a comment if I would have enough reputation,
but my guess is that the bashrc is not in your homefolder: ~/ but in the all users or general user folder(I dont know how it is named exactly). Look under your users where all users are located and search for .bashrc.
Look here : C:\Users\All Users
or: C:\Users\Default User
Related
I am loosing a lot of time searching in internet for the following simple setting.
I installed git (and git bash) in Windows. What I want is just to open Git Bash and be in the directory I want. I don't want to change my home directory, just be in a given directory when I open the program.
More detailed, when I open Mingw / Git bash in Windows, I would like to be in the following folder:
/c/blabla/my_git_repositories
(this corresponds to the windows-style path: C:\blabla\my_git_repositories).
At the moment, I must write the following command every time I open GitBash:
cd /c/blabla/my_git_repositories
is this possible? Which file should i modify?
Actually the program is installed here:
C:\Program Files\Git\mingw64
Thanks
If you want it happening every time you start an interactive shell, add
cd /c/blabla/my_git_repositories
to your shell startup. If your install includes the manpages say man bash and find the INVOCATION section, in a decent pager just /^INV will do it. Or Google knows to interpret a search for man bash as a search for the bash manpage.
Windows doesn't ordinarily support shell logins at all so a lot of the shell's startup-circumstance detection is overkill on Windows. Executing it is extremely fast, but describing exactly how it decides takes a page or two.
The short form is, if the startup was told it's a login shell it reads the login startup files, including (your) ~/.bash_profile, which generally should check for an interactive login and if so source the normal interactive shell startup ~/.bashrc, so ~/.bash_profile should end with something like
[[ $- = *i* && -f ~/.bashrc ]] && . ~/.bashrc
and put whatever you want in ~/.bashrc. That cd, set up your prompt colors, define your favorite shell aliases, add your personal scripts directory to PATH, whatever.
Partial solution when opening the program by clicking on a link.
Right click on the link → properties → Start in: set the value to "C:\blabla\my_git_repositories".
This will work only when you open the application from that link, but could be fine (depending by your needs).
Backup, first.
Before attempting to resolve this, people are worried about $PATH changes breaking things. Backup your path with echo $PATH > $HOME/bak/conf/path.bak and remember (don't put any raw files into the bak dir). Confirm your backup with cat $HOME/bak/conf/path.bak.
A minimal $PATH!
My desired path is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin.
This is a minimalist path that should break nothing on most default Linux installs (Backup, first).
I have a huge $PATH that is completely useless (like 120 lines of $PATH--caused by WSL [more later]). So far, I only know how to add to path and remove single directories from $PATH via seg.
Sounds like it should pop right up on search engines. I have a headache in my eye--:
how do I set $PATH to a raw string or purge it so I can append from null?.
Bonus points for anyone who can tell me how to set $PATH from the contents of a file!?
Best guess:
import sys, sys.path.insert(0, '/your/path')--!NO This did not work!
Temporary workaround:
You can move the path to a neutral file (or use whatever means you know) and replace / with / and then use sed to cut the unwanted part out:
PATH=$(echo "$PATH" | sed -e 's/:\/tons:\/of:\/unwanted:\/garbage$//')
Make sure you put everything you don't want between s/ and $//').
Where is this long $PATH coming from?
Related question: How to remove the Win10's PATH from WSL --$PATH is inherited every time you re-launch or perform some other actions such as possibly changing users or environments.
Why is this question different:
As if there isn't enough typing, S.O. has a nuisance dialog that asks me to write and explain why purging $PATH is different from removing one directory/path from $PATH.
Because a punch in the face isn't a kick in the butt.
If I'm understanding your question, you simply want to know how to set your Bash PATH to a fixed string (or erase it completely) and have it persist across restarts of the shell?
If so, then I'll start off by saying that this isn't recommended as it will break other things. If not now, then later.
But if you really want to set the PATH to a fixed value every time Bash starts ...
Short answer first:
Assuming fairly "default" startup files (where ~/.profile sources ~/.bashrc):
Edit your ~/.profile (or ~/.bash_profile in the rare case it exists) and add:
# Remove entirely
unset PATH
export -n PATH
# Optionally
export PATH=/new/pathItem1:/new/path/Item2
Adding this to the bottom of the file should override any other PATH modifications done previously. However, future application installations can make modifications below that, therefore overriding it.
In a very rare case where you have an interactive Bash session that isn't startup by a login shell, you could also make the same modifications to ~/.bashrc.
(Not necessarily required if the modification is the last thing called during startup, but) make sure that there are no other PATH adjustments in your ~/.bashrc or ~/.bash_profile.
More explanation:
Where is this long $PATH coming from?
Your path in Bash in WSL can potentially come from a few sources:
WSL's init process sets a default PATH for the starting application (shell). This is currently (in WSL 0.70.8):
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib
Since this is done before your ~/.profile runs, there's no need to worry about disabling it.
As you've pointed out, WSL automatically appends the Windows path to the Linux path so that you can launch Windows executables. This can be disabled using the method in the question you linked, but it's not necessary if you simply want to override the entire PATH. Setting the PATH in your ~/.profile comes after WSL sets it for the initial process (your shell).
Bash itself has a built-in, default path that is hardcoded into it for "fallback" in case no other path is passed in. This rarely ever takes effect. Most Linux systems are going to set the PATH through some other mechanism, meaning the fallback never gets activated. A typical Linux system will set the default PATH via /etc/environment, but this isn't used under WSL since the init mechanism mentioned above is needed instead.
If using Systemd or another init system in WSL, then Bash (and other POSIX shells) will process /etc/profile and files in /etc/profile.d when starting. These files may contain PATH modifications. Again, since these come before your ~/.profile, (re)setting the PATH to a fixed value will override any of these settings.
Finally, your ~/.profile or ~/.bash_profile (for login shells) and ~/.bashrc (for interactive shells are read. Typically, PATH modifications in these files look something like:
export PATH="/new/path/item:$PATH"
This prepends to the path, making that new item take priority over the previous items.
However, leaving out the existing :$PATH part will simply set it to a string literal.
It should be obvious, but if you do this without including the "normal" OS paths, you will be unable to call any command that isn't built in to Bash already with specifying its fully qualified path. For instance, ls will fail. Note that you can still:
$ ls
ls: command not found
$ /usr/bin/ls
# works
Also note that ~/.profile is called for login shells. It is possible, however, to tell WSL to launch Bash without reading ~/.profile:
wsl ~ -e bash --noprofile
The resulting shell will still have the default WSL path in this case.
I am trying to fix the bash profile but it constantly says:
source ~/.bash_profile
/Users/KirSo/.bash_profile:160: command not found: bind
\[\e]2;\u#\h\a[\[\e[37;44;1m\]\t\[\e[0m\]]\[\033[0;31m\] (master) \[\e[32m\]\W\[\e[0m\]\n\[\e[0;31m\]\[\e[0;49;34m\]//\[\033[0;31m\] ♥ \[\e[0m\]
checked the line 160 which says:
bind "set completion-ignore-case on"
Although with adjust the line, restarting the terminal it still drops the same error.
Considering the path inside the question, You are probably running CygWin or something similar. Check the $PATH variable and Your env variables. You might have accidently changed the paths in which bash is looking for binaries (such as /bin). Also, on some versions of Linux (dont know about CygWin, sorry :<), there are other bash config files, namely ~/.bashrc /etc/bash.bashrc /etc/profile. The names may vary, depending on the distribution and implementation. Check If those contain code that overrides Your $PATH variable.
I am writing installation in a Makefile in which I need to set the PATH env. variable.
In the windows part of it, I found the following:
set: With set PATH="%PATH%;%CD%" I can change the PATH inside the running environment. There are two problems with this:
The environment is a spawned cmd.exe by make which gets its variable affected and the effect removed as soon as it closes
Even if the previous problem could be solved, still the cmd.exe that calls make would close one day and the modified PATH lost.
setx: A microsoft tool that can permanently change env. variables. According to microsoft itself, this is the only command-line option to do this. Using setx PATH "%PATH%;%CD%" -m however, turns path into the literal %PATH%;%CD% and doesn't replace the variables by their contents!
Note that I am calling make from cmd.exe not cygwin or other modified windows shells that act more like linux. What I'm saying is that, although I can use $(PATH) in my makefile (instead of %PATH%), I can't use pwd (instead of %CD%)
Also note that if in cmd itself I run:
setx PATH "%PATH%;%CD%" -m
it works perfectly. Somehow I need to make make execute this command.
Do you have any idea how to fix this, or what workaround do I have?
P.S. Just for the record, echo "%PATH%;%CD%" in the Makefile also echoes the literal "%PATH%;%CD%" rather than let cmd.exe handle it
Back in the day i Borland C++ Free Command Line tools included a version of make which played well with the dos/windows command line. Probably still floating around somewhere.
Workaround:
Create a .bat file, put the command there, and invoke it from the Makefile.
I still am interested in a direct fix in the Makefile though.
I'm using msysgit 1.7.7.1 on Windows. I get an error when using git diff. What is causing this? Is there no diff tool included in msysgit? What should I do?
WARNING: terminal is not fully functional
If you are having issues in cmd.exe, for instance, see the warning here:
Then simply set your environment variables and include TERM=msys. After that, each time you open a cmd.exe, your variable will be set correctly.
NOW YOU MUST RESTART YOUR SHELL (CMD.EXE). Just run a new one. And from there, you should have no more issues. Again:
For Git Bash, this can be fixed by adding the following line to ~/.bashrc:
export TERM=cygwin
-or-
export TERM=msys
The first seems to be the original by git for windows, the second a popular known form to "heal" as well.
The problem can be caused if some other program (like for example Strawberry Perl) sets the TERM system environment variables.
http://code.google.com/p/msysgit/issues/detail?id=184
Above answers was not fully worked for me, so I did:
Add
export TERM=msys
to "[githome]/etc/profile" at the top but it made changes only for git bash. Then I added
#set TERM=msys
to "[githome]/cmd/git.cmd" after #setlocal (I installed only git run from command line). May be this decision not truly good but it works for me and there are not any terminal warnings. (I use git version 1.7.10.msysgit.1).
The answer can be found here, in which the author of the solution claims that:
the environment variable TERM was set to dumb
that was instead of
TERM=cygwin
You can change that to
TERM=msys
to solve the problem at hand.
I work in powershell and I have the git executable directly in my path.
None of the suggested answers worked, but I found a solution that works for me.
I added a line in my powershell profile:
$env:TERM="msys"
Which fixed the problem for me.
A quick & dirty solution in my case turned out to be to use the --no-pager option.
By default, some git commands (like log) will use a pager like less if they expect the output to be long. Pagers require things like scrolling text up and down with the arrow keys, which sometimes doesn't work if the assumptions about what kind of terminal you're on are wrong (this is what the "not fully functional" means).
If you know ahead of time that your output will be short, or you just want it to dump output to the terminal and leave the scrolling up to your terminal program, you can override this and not use a pager at all, e.g.:
git --no-pager log
In case someone gets this launching bash from Git Extensions, check the setting for Path to linux tools.... Mine was set to C:\cygwin. Changing it to C:\Program Files (x86)\Git\bin\ fixed it for me. I didn't have to set the TERM variable to launch bash this way.