.bashrc file didn't load when start bash in windows

[yhvicey]

First, I entered WSL but it looks abnormally - no color and alias:

And if I enter bash again everything goes to work normally:

So what's wrong with my WSL? How to recover it? Thanks.

[sunjoong]

@yhvicey - ll is an alias in ~/.bashrc file like this; alias ll='ls -alF'. I guess bash.exe just spawn /bin/bash process, not reading ~/.bashrc file. Try this;

• You can find bash.exe shortcut named Bash on Ubuntu on Windows in "C:\Users\sunjoong\AppData\Roaming\Microsoft\Windows\Start Menu\Programs" directory; sunjoong is my username, so it might be yhvicey in yours.

• The property of that shortcut is;

C:\Windows\System32\bash.exe ~

• Change that like this;

C:\Windows\System32\bash.exe ~ -l

Option -l means like LOGIN; it's lowercase of L, not capital of i. Then, bash will read ~/.profile file and ~/.profile file read ~/.bahrc file.

[yhvicey]

@sunjoong After installation there is no short cut in start menu so I created one manually:

After adding "-l" to target I tried again but still doesn't work. I guess it has nothing to do with shortcut because there's same issue if I start %WINDIR%\System32\Bash.exe directly.

And this problem seems to appear in recent insider builds. Or, I have changed the color of the bash console. Does it matters?

[sunjoong]

@yhvicey - Something's wrong!!

1. Shortcut should exist.
2. ~/.bashrc file should be read even without any options.
3. ~/.profile file should be read with -l option.

I meant -l option, not shortcut. Sorry, I have no idea but know something's wrong in recent insider builds.

[yhvicey]

@sunjoong

1. Due to poor network I download install package manually and install it by hooking network request by Fiddler, I guess that's why I don't have a shortcut.
2. It seems that my bash didn't execute ~/.bashrc when I open it, neither through shortcut nor open it directly.
3. Thanks for you information.

[sunjoong]

@yhvicey - This is not a solution becasue that not reading ~/.bashrc file issue might not removed, but... you said runnig /bin/bash manually worked, so... it might be an emegency trick, I think.

Try -c /bin/bash like this;

C:\Windows\System32\bash.exe ~ -c /bin/bash

[yhvicey]

@sunjoong It works, thanks for your workaround.

[0xbadfca11]

Before than 16184, bash's argv[0] is '/bin/bash'. This is non-login shell. Bash will only loads .bashrc.
Starting 16184, bash's argv[0] is '-bash'. This is login shell. Bash loads only the first one in .bash_profile or .bash_login or .profile. Don't see .bashrc. However, the default .profile will executes .bashrc.
Let's load .bashrc yourself when using .bash_profile or .bash_login which has higher priority than .profile.
Even if '-l' is added, .bashrc is not loaded because there are files with higher priority than .profile.

[sunjoong]

@0xbadfca11 - Thanks for notice; that's very important news.
@yhvicey - You have ~/.bash_profile and ~/.profile both, but ~/.bash_profile would be read if bash be a login shell and you have ~/.bash_profile. Check your ~/.bash_profile to have these lines;

if [[ -f ~/.bashrc ]] ; then
	. ~/.bashrc
fi

You might find simular thing in ~/.profile but you have ~/.bash_profile, so check that file.

[yhvicey]

@0xbadfca11 Thank you very much. I have created a .bash_profile file to disable bell before.
@sunjoong These codes are in my ,profile file and I'll merge these files to solve this. Thanks for your help.

[tito433]

@sunjoong , I was having the same problem. Your code solved mine.

[ChaosFreak]

@sunjoong Your answer is perfect! It fixed it for me.

[vunb]

@sunjoong It works for me. Thanks!

[r4k0nb4k0n]

@sunjoong Thank you for your answer!

[psxvoid]

Posting it because it may help someone. For me, all the solutions above didn't work.

After starting WSL, when ssh-agent was asking for a password, I always pressed Ctrl+C to skip it. When I entered (remembered) it, the ./bashrc was loaded correctly.

It seems like I was breaking the loading process of ./bashrc

[BengtOFFIS]

This worked for me:

"ubuntu1804" run bash -login

[AMDphreak]

This problem is more difficult to solve for WSL installations installed from the Microsoft Store (Windows App Store).

Finding the directory for the shortcut that launches the bash.exe shell is not that straightforward for any App Store app, because the Start Menu entries do not allow you to go to the link location on disk:

To work around this: run the Linux command line you installed,

• open up Task Manager (Right click Start Menu),
• go to the Advanced mode
• click on the Details tab
  Look in the list of running processes for your linux terminal (mylinuxdistro.exe). For example, Debian:

Right click on the exe file and click Open File Location. This locates the shortcut in File Explorer:

And as you can see, the "link" is unfortunately not a link, but a .exe file, so this shortcut hack doesn't work here.

[bikrambox]

@0xbadfca11 - Thanks for notice; that's very important news.
@yhvicey - You have ~/.bash_profile and ~/.profile both, but ~/.bash_profile would be read if bash be a login shell and you have ~/.bash_profile. Check your ~/.bash_profile to have these lines;

if [[ -f ~/.bashrc ]] ; then
	. ~/.bashrc
fi

You might find simular thing in ~/.profile but you have ~/.bash_profile, so check that file.

Man This works perfectly. //i just added this in both of them (Thinking whichever works and it did. #admit not the best pro work but it works.)

[gmag11]

I've found that in my system only .bash_profile is executed. So I added this to it:

if [[ -f ~/.profile ]] ; then
        . ~/.profile
fi

Now it works

[stefanrows]

@0xbadfca11 - Thanks for notice; that's very important news.
@yhvicey - You have ~/.bash_profile and ~/.profile both, but ~/.bash_profile would be read if bash be a login shell and you have ~/.bash_profile. Check your ~/.bash_profile to have these lines;

if [[ -f ~/.bashrc ]] ; then
	. ~/.bashrc
fi

You might find simular thing in ~/.profile but you have ~/.bash_profile, so check that file.

I confirm that this works.

[MartinDevillers]

@0xbadfca11 - Thanks for notice; that's very important news.
@yhvicey - You have ~/.bash_profile and ~/.profile both, but ~/.bash_profile would be read if bash be a login shell and you have ~/.bash_profile. Check your ~/.bash_profile to have these lines;

if [[ -f ~/.bashrc ]] ; then
	. ~/.bashrc
fi

You might find simular thing in ~/.profile but you have ~/.bash_profile, so check that file.

This comment is 3 years old but solved an issue I had today. I recently setup a new system with Windows 10, WSL 2, Ubuntu, Windows Terminal, Node, Python, Visual Studio Code, all the latest greatest. Things worked fine until this morning after an automated restart by Windows update. The terminal lost its color and none of the packages I installed (e.g. node, nvm, npm, etc) were recognized anymore. Adding the above the lines to lines to my .bash_profile brought everything back to life, so kudos for that. I'm not sure what broke things in the first place. I can see my home dir has both a .bash_profile, .bashrc and a .profile file. My guess is that the .bash_profile was created by some other tools I installed later like pip or python and that this "overrides" the settings from .bashrc, which didn't become apparent until after a reboot.

[yusufkhan07]

@0xbadfca11 - Thanks for notice; that's very important news.
@yhvicey - You have ~/.bash_profile and ~/.profile both, but ~/.bash_profile would be read if bash be a login shell and you have ~/.bash_profile. Check your ~/.bash_profile to have these lines;

if [[ -f ~/.bashrc ]] ; then
	. ~/.bashrc
fi

You might find simular thing in ~/.profile but you have ~/.bash_profile, so check that file.

Thank you so much, I spent hours on finding a solution and this finally worked.
The problem was ~/.bashrc wasn't being loaded but adding the lines you mentioned in ~/.bash_profile fixed that.
I had to restart VS Code for changes to take effect in VS Code.

[stevenrbrandt]

I had this same issue. It turns out that the problem is a faulty /etc/bash.bashrc. It doesn't call ~/.bashrc. I added the following to my /etc/bash.bashrc and all is well.

if [ -f "$HOME/.bashrc" ]
then
source $HOME/.bashrc
fi

[asteinarson]

@stevenrbrandt : Yes, it solves the issue when running with Windows Terminal + WSL Ubuntu.
So it must really be an issue with this Ubuntu release [20.04] (?). That is strange - It does not happen in Ubtuntu 20.04 when running native.
Anyhow, happy to have the workaround.

[baranaldemir]

@0xbadfca11 - Thanks for notice; that's very important news.
@yhvicey - You have ~/.bash_profile and ~/.profile both, but ~/.bash_profile would be read if bash be a login shell and you have ~/.bash_profile. Check your ~/.bash_profile to have these lines;

if [[ -f ~/.bashrc ]] ; then
	. ~/.bashrc
fi

You might find a simular thing in ~/.profile but you have ~/.bash_profile, so check that file.

Thanks for @sunjoong 's answer. It works very well. But I think it still doesn't solve the problem directly. Here is the output of pstree after the problem occurs.

and I believe this is the output of pstree it should be.

Probably, because I'm an obsessive person it still bothers me 😅. I hope to find or see some answer to fix this.

[stevenrbrandt]

@baranaldemir yes, I tried all those things before I came up with my fix. I've since switched to MobaXterm. Everything seems to just work better there, though I didn't check specifically for this issue.

[Cornelius-Figgle]

Had the same issue, but only when using a instance I manually created the user for. I found the .profile was called but didn't source anything else as bash wasn't running? I changed the .profile to contain an exec bash line and that fixed the issue for me

...

exec bash

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

...

EDIT: it also starts with the following command:

wsl -e bash