Update: just noticed that on a more advanced ~/.profile, I see it sourcing ~/.bashrc only if under bash (by using if [ -n "$BASH_VERSION" ]; ).
As Debian sid was just unfrozen due to Squeeze release, I recently get lots of package updates. I had the feeling that something is gonna break, even slightly, despite the relative high stability of Debian unstable.
And indeed, after 100+ updates, I could no longer login to GNOME. I'm not sure which package update caused this (bash_completion was updated to 1.3, yet the problem isn't necessarily there) . gdm nicely referred me to ~/.xsession-errors, which had something like:
sh: /etc/bash_completion.d/git: line 123: syntax error near unexpected token <' done < <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream) 2>/dev/null | tr '\0\n' '\n ')'
sh: /etc/bash_completion.d/git: line 123:
sh: _grub_mkpasswd-pbkdf2': not a valid identifier_grub_script-check': not a valid identifier
sh:
I couldn't find any related Debian bug report, nor hardly anything on the internet (just some Arch Linux bugs with no clear solution).
Eventually I've found out that /etc/gdm/Xsession uses /bin/sh (a crippled shell, even though it's a symlink to /bin/bash), which indeed fails with the same error when running 'source /etc/bash_completion'. This makes sense. bash_completion[*] should be bash-compatible, and may include bash-only non-standard-shell compliant syntax.
Wondering why Xsession gets to run ~/.bash_completion indirectly, I've found that I had the following two abominations:
- 'source ~/.bashrc' command in ~/.xsession
- 'source ~/.bashrc' command in ~/.profile
I'm not sure why I had these lines, but they shouldn't be there. Bash itself and only bash should source ~/.bashrc (and it's done automatically when bash starts). It makes no sense for other shells to source it.
So the solution was simply removing these lines from ~/.profie and ~/.xsession (actually got rid of ~/.xsession completely). Still, I'm not sure which update triggered this problem.
----
* Actually the problem was in /etc/bash_completion/git which is a part of the 'git' package and not the 'bash-completion' package. But all the same.
Thank you a ton for blogging this. I had exactly the same problem. Could startx my gnome, but not successfully log into gnome from gdm.
Turns out I had a PATH="..." without sourcing the previous variable in ~/.profile. My ~/.xsession-errors showed lots of not found basic commands because /usr/bin/ was no longer in the path specifically for gdm's own Xsession:
/etc/gdm/Xsession: Beginning session setup...
unable to find device pointer:Logitech USB Receiver
/etc/gdm/Xsession: regel 143: xmodmap: opdracht niet gevonden
/etc/gdm/Xsession: regel 156: id: opdracht niet gevonden
/etc/gdm/Xsession: regel 156: xhost: opdracht niet gevonden
/etc/X11/xinit/xinitrc.d/00-xhost: regel 7: id: opdracht niet gevonden
/etc/X11/xinit/xinitrc.d/49-keychain: regel 5: which: opdracht niet gevonden
/etc/X11/xinit/xinitrc.d/50-ssh-agent: regel 5: which: opdracht niet gevonden
/etc/gdm/Xsession: ssh-agent not found!
/etc/gdm/Xsession: Setup done, will execute: gnome-session
/etc/gdm/Xsession: regel 196: exec: gnome-session: niet gevonden
Easiest way to debug is to add an "echo $PATH" to /etc/gdm/Xsession somewhere halfway (above the xhost line) if you get these sorts of errors.
I also had the git bash-completion problem. Now I finally sorted all my shell scripts.
Thanks
Similar issue here.
In my .bashrc I have defined a function named 'l.' to list dot-files only.
This has worked with all linuxes so far and does not issue an error with bash when I source .bashrc so I regard it as an allowed function name.
After I upgraded to ubuntu12 I get the following entry in my .xsession-errors
/root/home/bmdadm/.bashrc: line 70:
l.': not a valid identifier_apport-bug': not a valid identifierI have commented the function and then get
cat .xsession-errors
/etc/bash_completion.d/apport_completion: line 107:
What a shit is going on here?
It seems that the latest Xserver has some bugs or flaws.
Got rid of that (at least I think) with:
$ sudo mv /etc/bash_completion.d/ /etc/bash_dummy
Strangely, I still have completion in my shell.