NOTE: Please see my second edit below for an update on the problem.

Cygwin was working fine for me until last week. Now .bashrc isn't getting sourced. I must have installed something or changed something but I can't remember exactly what caused the problem. When I start Cygwin, I'm in my Windows home and none of my aliases work. I have to manually source .bashrc. The following is my Cygwin.bat:

@echo off

chdir C:\cygwin\bin

set CYGWIN=tty notitle glob

bash --login -i

Any ideas?

EDIT: My .bash_profile contains the following,

# source the users bashrc if it exists
if [ -f "${HOME}/.bashrc" ] ; then
  source "${HOME}/.bashrc"

EDIT2: IMPORTANT! When I started Cygwin it starts in my Windows home folder. I tried putting my .bash_profile and .bashrc in this folder and they were sourced correctly! This means that the problem has been reduced to figuring out why Cygwin starts in the Windows home folder and not the normal Cygwin home folder.

EDIT3: Results of running grep Gulshan /etc/passwd/

$ grep Gulshan /etc/passwd
  • When your bash shell starts (and puts you in your Windows home directory), what does echo $HOME print? – Keith Thompson Mar 1 '12 at 0:44
  • It echoes my Windows home, not my Cygwin home. – gsingh2011 Mar 1 '12 at 0:52
  • But using Cygwin syntax, right? (/cygdrive/c/Users/foo rather than C:\Users\foo) – Keith Thompson Mar 1 '12 at 0:55
  • Yes, using Cygwin syntax. – gsingh2011 Mar 1 '12 at 0:56
  • What happens when you type HOME=/home/yourname bash -l at the terminal prompt? If I'm right, this should give you properly working shell. Note that this is a diagnostic, or at best a workaround, not a solution; we still need to figure out why your $HOME is incorrect in the first place. The root problem is the incorrect setting of $HOME; bash is behaving correctly. – Keith Thompson Mar 1 '12 at 0:57

The Cygwin FAQ explains how $HOME is set:

When starting Cygwin from Windows, HOME is determined as follows in order of decreasing priority:

  • HOME from the Windows environment, translated to POSIX form.
  • The entry in /etc/passwd
  • /home/USERNAME

When using Cygwin from the network (telnet, ssh,...), HOME is set from /etc/passwd.

If your HOME is set to a value such as /cygdrive/c, it is likely that it was set in Windows. Start a DOS Command Window and type set HOME to verify if this is the case.

Access to shared drives is often restricted when starting from the network, thus Domain users may wish to have a different HOME in the Windows environment (on shared drive) than in /etc/passwd (on local drive). Note that ssh only considers /etc/passwd, disregarding HOME.

My best guess is that you've messed up your /etc/passwd file. (The Windows home directory is %USERPROFILE%, not %HOME%.)

What does grep USERNAME /etc/passwd print (replacing USERNAME with your user name)?

  • I've added the output to my question so it's easier to read. It looks like it's set correctly there. However, I opened up my Windows Environment variables to see if there was a %HOME% variable and there was and it was set to %USERPATH%. I removed it, but it didn't solve my issue. Maybe it needs a restart? – gsingh2011 Mar 1 '12 at 1:14
  • 1
    Did you remove it from the System control panel, or from a Windows command shell using set HOME=? Using the System control panel is more likely to work, but a restart might be necessary even then. – Keith Thompson Mar 1 '12 at 1:19
  • I removed it by right clicking on Computer in the start menu, clicking on properties, clicking on advanced system settings, then environment variables, and then removing HOME. A restart was necessary. Now Cygwin loads the right home directory. Thanks for the help. – gsingh2011 Mar 1 '12 at 1:31

If you have a .profile or .bash_profile, that is sourced on login shells, and you get a login shell since you pass --login. If you source .profile, then bash will not source .bashrc.

I'd try to put:

[ -f $HOME/.bashrc ] && source $HOME/.bashrc

in your .profile, see if that helps. Your .bashrc should still be sourced, as normal, in other non-login shell invocations.

And don't pass -i to bash; you don't need it. Bash kind of hacks that in, pretends you gave -i on the command line.

  • My .bash_profile and .profile have similar lines of code. See my updated question. – gsingh2011 Mar 1 '12 at 0:14
  • Excuse me, @Rich Homolka, but I would like to know why do you say that -i is not necessary. Thanks. – Sopalajo de Arrierez Mar 4 '14 at 14:41
  • @SopalajodeArrierez if you have an interactive (not a script, but active at a terminal) shell, bash pretends you gave it -i on the command line. Try opening a bash shell window, then echo $-, you should see i (among possibly other flags) – Rich Homolka Mar 4 '14 at 15:07

I experienced the same behavior - probably after having git (Windows) installed.

In the system setting I've found the user variable HOME=C:\Users\me and reset this to HOME=D:\home

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.