Tag Archives: bash

Solution for Xsession + bash_completion problem

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 <'
sh: /etc/bash_completion.d/git: line 123:
done < <(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream) 2>/dev/null | tr '\0\n' '\n ')'
sh: _grub_mkpasswd-pbkdf2': not a valid identifier
_grub_script-check': not a valid identifier

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.

bash evilness

I've been trying to read a file in bash, and keep all the lines in a single variable, printing it at once after the loop:

cat /tmp/myfile | while read line; do
all="$all $line"
echo $all

However the output was only: EVIL_BASH, instead of having the lines of the /tmp/myfile appended.


Because of the PIPE, the whole 'while' loop runs in another subshell. This means that $all outside the loop  is not the same $all from within the loop!

Sounds simply like scoping (as in perl), but a really awkward one. Beware.