.profile not sourced anymore

looks more like it's the .profile that is not sourced anymore

Doing "source .bashrc" doesn't even get my .bashrc in anymore. This is a BIG bug. It appears as though all of "source" is broken. Even ". .bashrc" is bad.

I think this is related to a bug with /etc/bash_completion. I set
   export BASH_COMPLETION_DEBUG=1
in my ~/.bashrc and this is what I see:

me@ubuntu:~$ . .bashrc

# Alter the following to reflect the location of this file.
#
{
  # These declarations must go within braces in order to be able to silence
  # readonly variable errors.
  BASH_COMPLETION="${BASH_COMPLETION:-/etc/bash_completion}"
  BASH_COMPLETION_DIR="${BASH_COMPLETION_DIR:=/etc/bash_completion.d}"
} 2>/dev/null || :

If I remove the 2>/dev/null, I see this error:

bash: BASH_COMPLETION: readonly variable

It appears that bash is dying on this line and not executing any commands which occur after it.

Temp fix is to remove sourcing of /etc/bash_completion from your ~/.bashrc

I can confirm the workaround

I hit this bug too, on amd64, after upgrading to gutsy beta.

This is a simple testcase:

 1. Put the following in a file named bash-bug.sh:
     -----8<-----
       echo 1
      {
              ROVAR="this variable is read only"
      } || .
      echo 2
      readonly ROVAR
      echo 3
    -----8<-----

    Note the "{ ... } || ." trick is exactly the same as the one at
    the beginning of /etc/bash_completion
 2. Run it once, sourced, like:
       $ source bash-bug.sh
    You should see it print up to 3.
 3. Run it again, in the same shell, like before.
     Now, here is where it differs: in ubuntu7, it works (it complains
     about ROVAR being read only, but it prints up to 3). In
     ubuntu11, it stops after the error.

If you were to "source bash-bug.sh" from a bash script (or, in the
common case, .bashrc or .profile), it would stop its execution too.

Now, I wanted to track the regression, so I took a look at ubuntu's
diff.gz, and noticed "upstream patch 20" which looked very
suspicious.

I then generated my own ubuntu11 package _without_ upstream
patch 20 (but all the others), and it worked just fine.

So I think patch 20 is causing this bug.

As a workaround, you can also avoid the variables readonly in
/etc/bash_completion.

If this patch is really upstream, I guess it should be reported. Should
I do it?

If the patch is correct (regardless of its upstream status), then
/etc/bash_completion needs to be fixed somehow.

Thanks a lot,
    Alberto

I can confirm both the bug and Michael Elkins's workaround.

For records discussion on the bug-bash ml: http://lists.gnu.org/archive/html/bug-bash/2007-08/msg00062.html

A note from the upstream maintainer re: this bug:

> Yes, I saw that a while ago. The post-patch20 behavior is correct,
> according to how I interpret the Posix spec.

> The real problem is that bash_completion defines a readonly variable
> and tries to assign to it. It's not like BASH_COMPLETION is built in.

> Chet

fixed in hardy

I was about to report this, but just happened to stumble over this bug report. Would it be nosy to suggest that the title of this bug be changed to better reflect the problem and its solution?

I agree with era. Also, as a temporary fix, I changed the last few lines of .bashrc to:

if [ -f /etc/bash_completion -a ! "$BASH_COMPLETION_HAS_RAN" ]; then
    . /etc/bash_completion
    export BASH_COMPLETION_HAS_RAN="1"
fi

This way, the bash_completion script gets to run once, on opening a login terminal, and then won't run again if you re-source your profile.

I ended up reporting it in 205444 again after all. That bug is marked "in progress".

My possibly incomplete understanding is that when you initially log in, the variables are not yet marked as read-only, so things sort of work, unless / until you try to source your .profile / .bashrc / what have you anew from within a bash session.

This was a bug in the bash-completion package and has been fixed in hardy.