| Summary: | app-shells/bash-completion-20060301 /etc/bash_completion and /etc/profile.d/bash-completion fail to load. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | DEMAINE Benoît-Pierre, aka DoubleHP <dhp_gentoo> |
| Component: | Current packages | Assignee: | Gentoo Shell Tools project <shell-tools> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | 1i5t5.duncan, decoder, Gentoo-bugs |
| Priority: | High | ||
| Version: | 2006.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 249271 | ||
| Bug Blocks: | |||
| Attachments: |
/etc/bash/bashrc
/root/.bashrc /tmp/emerge--info Log of what fixed ... |
||
|
Description
DEMAINE Benoît-Pierre, aka DoubleHP
2008-01-07 03:48:55 UTC
Created attachment 140349 [details]
/etc/bash/bashrc
modified /etc/bash/bashrc to magnify the problem : I just added two echo lines at the bottom.
Created attachment 140351 [details]
/root/.bashrc
/root/.bashrc that is executed when I log in.
There are two cases.
echo plaf 41
#source /etc/bash_completion
echo plaf 42
that produces this output:
dhp@moon_gen_2:~$ su
Password:
plop 1
plaf 1
plaf 2
plaf 3
plouk 31 a
plouk 31 c
plouk 31 d
plaf 40
plaf 41
plaf 42
plaf 43
plaf 5
plaf 6
plop 2
plaf 1
plaf 2
plaf 3
plouk 31 a
plouk 31 c
moon_gen_2 dhp #
and prooves my user bashrc is run twice, once by /etc/bash/bashrc between two PLOP, and one after plop 2 . Here we see the second run fails on /etc/profile.d/bash-completion
Second case, with:
echo plaf 41
source /etc/bash_completion
echo plaf 42
dhp@moon_gen_2:~$ su
Password:
plop 1
plaf 1
plaf 2
plaf 3
plouk 31 a
plouk 31 c
plouk 31 d
plaf 40
plaf 41
moon_gen_2 dhp #
here, execution fails on first run, on /etc/bash_completion .
Something went wrong after my weekly update. The problem is really visible to me, because I log in as root daily, and, I need my prompt to look like some very old habit host:$PATH all glued together, I cant stand at all the default spaced things in Gentoo. Thats why I remember I had my prompt friday, and not sunday.
Maybe remerge will fix ?
Created attachment 140352 [details]
/tmp/emerge--info
moon_gen_2 ~ # emerge -va1 app-shells/bash-completion [ebuild R ] app-shells/bash-completion-20060301 0 kB Did not fix. moon_gen_2 ~ # emerge -va1 app-shells/bash [ebuild R ] app-shells/bash-3.2_p33 USE="nls -afs -bashlogger -plugins -vanilla" 0 kB did not either. In fact, this did not even replace /etc/bash/bashrc in which I had put some ECHO ... despite etc-update and the log saying --- replaced obj /etc/skel/.bashrc --- replaced obj /etc/skel/.bash_profile --- replaced obj /etc/skel/.bash_logout --- replaced dir /etc/skel --- replaced obj /etc/bash/bashrc <<< obj /etc/bash/bash_logout --- replaced dir /etc/bash --- replaced dir /etc --- replaced sym /bin/sh --- replaced sym /bin/rbash --- replaced obj /bin/bash --- replaced dir /bin I dont understand what's hapening. Here is the list of what I emerge this week, so, let say this year :) . I filter against x11 because I remerged x11*/* to fix an X bug and that would introduce excessive noise.
dhp@moon_gen_2:~$ ls /var/log/portage/ |grep 2008 |uniq |grep -v "^x11"
app-admin:hddtemp-0.3_beta15-r3:20070920-200825.log
app-emulation:wine-0.9.52:20080101-222802.log
app-emulation:wine-0.9.52:20080105-220930.log
app-office:gnumeric-1.6.3:20080106-190839.log
app-office:gnumeric-1.8.0:20080106-185300.log
app-shells:bash-3.2_p33:20080105-220032.log
app-shells:bash-3.2_p33:20080107-040108.log
app-shells:bash-completion-20060301:20080107-035821.log
dev-libs:glib-2.12.9:20070207-200854.log
dev-libs:libcdio-0.79:20080101-220354.log
dev-scheme:guile-gnome-platform-2.15.92:20080105-230102.log
gnome-base:gconf-2.20.1:20080105-220906.log
gnome-base:gconf-2.20.1-r1:20080105-220551.log
kde-base:kdelibs-3.5.8-r1:20080106-023427.log
kde-base:kdelibs-3.5.8-r2:20080106-001114.log
media-gfx:imagemagick-6.3.7.8:20080106-023500.log
media-libs:libpixman-0.1.6:20080104-182514.log
media-libs:libquicktime-1.0.1-r1:20080106-193026.log
media-libs:libsdl-1.2.13:20080101-222211.log
media-libs:musicbrainz-2.1.5:20080101-214831.log
media-plugins:audacious-plugins-1.4.4:20080106-193759.log
media-sound:audacious-1.4.5:20080106-193543.log
media-sound:mpg123-1.0.1:20080101-222545.log
media-sound:rezound-0.12.3_beta-r1:20080101-220631.log
media-video:mplayer-1.0_rc2_p24929-r1:20080106-190844.log
net-firewall:iptables-1.4.0-r1:20080101-215011.log
sys-apps:pciutils-2.2.9:20080101-214659.log
sys-apps:portage-2.1.4_rc14:20080101-214455.log
sys-devel:gdb-6.7.1-r1:20080101-215144.log
sys-fs:e2fsprogs-1.40.4:20080101-220143.log
sys-kernel:linux-headers-2.6.23-r3:20080101-214753.log
sys-libs:com_err-1.40.4:20080101-215945.log
sys-libs:readline-5.2_p12-r1:20080105-220433.log
sys-libs:ss-1.40.4:20080101-220052.log
sys-libs:timezone-data-2007k:20080101-214727.log
www-client:mozilla-launcher-1.57:20080101-215130.log
dhp@moon_gen_2:~$
hmmm seem to be a bash update:
app-shells:bash-3.2_p33:20080105-220032.log
genlop -t
reports:
Wed Aug 8 11:19:40 2007 >>> app-shells/bash-3.2_p17-r1
merge time: 3 minutes and 19 seconds.
Sat Jan 5 23:04:33 2008 >>> app-shells/bash-3.2_p33
merge time: 4 minutes and 2 seconds.
Mon Jan 7 05:04:53 2008 >>> app-shells/bash-3.2_p33
merge time: 3 minutes and 46 seconds.
Mon May 7 13:33:34 2007 >>> app-shells/bash-completion-20060301
merge time: 11 seconds.
Mon Jan 7 04:58:37 2008 >>> app-shells/bash-completion-20060301
merge time: 16 seconds.
If we forget about Jan 7th that was a manual remerge, wee that I have been using the same bash and bash-completion for the last 6 months. So, the bug may lay in the p33 recent update of bash. I did a weekly update on Xmas week; ls -l /usr/portage/app-shells/bash/ confirms that p33 is recent. I will mask it, and see if I recover the old behaviour.
Created attachment 140359 [details]
Log of what fixed ...
downgrade from p33 to p25 does not seem to help.
But there is a funny thing; I did emerge -C bash . Removal failed because python seems to depend on bash to run emerge, so, as the binary was removed, emerge crashed. I tried to emerge bash again, what failed for obvious reasons. Then, I did:
cp -a /mnt/debian/bin/bash /bin
and now, bash behaves like before. I have normal completion, and personalised prompt:
dhp@moon_gen_2:~$ su
Password:
root@moon_gen_2:/home/dhp# emerge -va1 apache
apache apache-mode apache-tools apachetop
root@moon_gen_2:/home/dhp# emerge -va1 apach
So, the think making mess have been "kept" by p25 re-install, but removed when I did ... see log attached.
At the end of the log, you see that when I enter a enw bash, I get my expected prompt.
The problem has hit me too. I've just merged bash-3.2_p33, and immediately, new shells didn't complete their sourcing of .bashrc as they failed to load bash-completion. That left me with an incomplete path; the reason I noticed it. I run FEATURES=buildpkg so had the old bash-3.2_p17-r1 as a binpkg. Remerging it immediately solved the problem. So the problem would seem to be the new bash. It may be worth masking it until this is worked out, as it's not just bash-completion that's killed, but anything after it in .bashrc. Ask if you want emerge --info, or if the emerge log for the bad bash (or any file that would be in its binpkg, for that matter) might be helpful. Traced the problem a bit further. With the defective _p33 merged, setting BASH_COMPLETION_DEBUG=1 (as noted in /etc/bash_completion) results in ONLY the following output from it:
# 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 || :
There follows a further line from bash, setting the prompt it's about to display as it aborts further init-file processing, but that's it. It never parses the next line, setting those vars readonly.
... After a bit more debugging, including removing that STDERR redirect to /dev/null, it appears BASH_COMPLETION is read-only when that line executes, thus causing a readonly error. That apparently aborts the sourcing right there -- the BASH_COMPLETION_DIR assignment is never reached. Even putting an || : (or even an || /usr/bin/yes) on the end of the bad assignment itself (instead of the grouping) doesn't cure the problem -- the sourcing still aborts and drops bash immediately to the prompt.
* I also checked _p25 and it too suffers this problem, so the problem would appear to be introduced between _p17 and _p25.
OK, the immediate reason I'm having problems here is because both /etc/profile and ~/.bashrc are sourcing some of the same files (including bash_completion) here. Since both may be sourced... That's why bash_completion is finding those vars already set readonly. So in this particular instance, it's a local issue. I'd wager that's what DoubleHP is running into as well. HOWEVER: This change of behavior for readonly vars is likely to have wider consequences. Who knows where readonly vars may be set, with further attempts to reset under the assumption that errors can be caught instead of aborting the script? I'd call this an upstream bug, apparently undocumented at present, and certainly not an appropriate behavior change for a same-version patchlevel bump. Duncan yes my user RC sources again /etc things. But, as I learnt in C langage programming, it should be the sourced library that should detect by itself that it has been previously sourced; in C, we use #ifndef mylib.h #define mylib.b /* content of the lib */ #endif All headers use this, to avoid multiple declaration and inclusion of headers. /etc/bash_completion should have the same kind of "protection" But, I disagree with your point in comment 9: if you read enotices, users are invited to source /etc/bash_completion, so, if this is already done in system whide scripts, there is no way we can expect or ask the user to remove what we asked him to previously put. My $(HOME) is common for several systems. This is a regression bug. I will mask p25 and p33, and hope I recover the old functionality. There is no way I alter my user conf; this would mean that 99% Gentoo users who are likely to have sourced these accordingly to enotices ... will also have to revert if the package ever get stable. We need a quick mask of both. *** *** *** Masked p25 and p33, downgraded, recovered working system. I dont know why genlop mentioned p17, and after masking p33 first time I did not pay attention to the fact it was offering me to install p25 instead of p17 ... (In reply to comment #2) > and prooves my user bashrc is run twice, once by /etc/bash/bashrc between two > PLOP, and one after plop 2 . Here we see the second run fails on > /etc/profile.d/bash-completion /etc/bash_completion declares BASH_COMPLETION{,_DIR} readonly. As of bash-3.2_p20 trying to change a readonly variable is fatal. So as you say it gets run twice this is expected behaviour with >= _p20. (In reply to comment #11) > /etc/bash_completion declares BASH_COMPLETION{,_DIR} readonly. As of > bash-3.2_p20 trying to change a readonly variable is fatal. So as you say it > gets run twice this is expected behaviour with >= _p20. > I just had the same problem because bash-completion was sourced twice. I agree that this is expected behavior and is ok, however it should be clearly visible to the user what is going wrong. I just spend over an hour searching for the reason why my .bashrc is being interrupted and why bash-completion is failing because you do not get a single error message during the whole process. I suggest to modify the bash-completion script to warn if it is loaded twice and then die instead of silently dieing (the /dev/null redirect part eats the vital error message) (In reply to comment #12) > (In reply to comment #11) > > > /etc/bash_completion declares BASH_COMPLETION{,_DIR} readonly. As of > > bash-3.2_p20 trying to change a readonly variable is fatal. So as you say it > > gets run twice this is expected behaviour with >= _p20. > > I do not understand: how could "running twice a script that declares a read only variable" not fail ? > I just had the same problem because bash-completion was sourced twice. I agree > that this is expected behavior and is ok, however it should be clearly visible > to the user what is going wrong. I just spend over an hour searching for the > reason why my .bashrc is being interrupted and why bash-completion is failing > because you do not get a single error message during the whole process. Crashing without error is the new wave of doing computing. It's inspired from Windows 2k rebooting automatically without warning; this behaviour has been ported to Gentoo/Linux; see bug 210710 > I suggest to modify the bash-completion script to warn if it is loaded twice > and then die instead of silently dieing (the /dev/null redirect part eats the > vital error message) I suggest to stop loading twice a script that have already been loaded, and stop declaring READ_ONLY a variable that is going to be overriden later on. app-shells/bash-completion-20081218 is in the tree and should fix this bug. Reopen if the problem persists in the new version. Thanks for reporting! |
