Bug 1085834 - In latest bash build, 'bash -l' no longer reads ~/.bashrc
In latest bash build, 'bash -l' no longer reads ~/.bashrc
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Dr. Werner Fink
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-19 14:11 UTC by Peter Sütterlin
Modified: 2018-05-15 14:23 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
bash -l -x trace (2.05 KB, text/plain)
2018-03-19 15:29 UTC, Peter Sütterlin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Sütterlin 2018-03-19 14:11:27 UTC
With update to TW 20180313 (bash 4.4-103.1 -> 4.4-103.2) bash login shell (bash -l) no longer reads $HOME/.bashrc

DimStar suspects:

  "Most likely, a silent break by a depedency change, which configure no
   longer detects."

Falsely reported as ssh issue in https://bugzilla.opensuse.org/show_bug.cgi?id=1085771
Comment 1 Dr. Werner Fink 2018-03-19 14:40:00 UTC
As the source had not changed I'd like to mention that this could also a change below /etc/profile.d/ which does not belong to bash nor aaa_base

Please provide an traced output of bash -l by adding option -x
Comment 2 Dr. Werner Fink 2018-03-19 14:41:53 UTC
Btw: Is this a remote or local login via bash?  And which variables are exported by the ssh with latest/you Tumbleweed
Comment 3 Dr. Werner Fink 2018-03-19 14:52:38 UTC
Here it works

rpm -qf /bin/bash
bash-4.4-103.2.x86_64
rpm -qf /etc/profile
aaa_base-84.87+git20180208.8eeab90-2.1.x86_64

[...]
+ is=bash
+ unset _is_save
+ test false = true
+ test bash = bash -a -z ''
+ readonly _HOMEBASHRC=true
+ _HOMEBASHRC=true
+ test -r /root/.bashrc
+ . /root/.bashrc
++ test -n ''
+ test bash = ksh -a -r /etc/ksh.kshrc
+ test false = true
+ case "$-" in
+ test xterm = xterm -a -O /dev/pts/4 -a -z /dev/pts/4
+ unset ORIG_PATH
+ unset is
Comment 4 Peter Sütterlin 2018-03-19 15:29:02 UTC
Created attachment 764111 [details]
bash -l -x trace

This is somewhat weird.  Attached is the log, the issue seems to be the is / _is_save variables.  This is from /etc/bash.bashrc, which is from aaa_base-84.87+git20180208.8eeab90-2.1 on both machines I have, but the file is actually different!?

The (non-working) updated one has an ages old (for TW) version 
woodstock:~% l /etc/bash.bashrc
-rw-r--r-- 1 root root 9598 Aug 14  2017 /etc/bash.bashrc

whereas the older one with TW 20180312 I have
lux:~% l /etc/bash.bashrc
-rw-r--r-- 1 root root 9625 Feb  8 14:01 /etc/bash.bashrc

I checked the zypper log, and there were no errors reported.  So I did a 'zypper in -f aaa_base', but the file was *not* changed.  
I then removed it, and forced the reinstall again.  *Now* I have the new version.

Now I also have the Feb 8 version and it's reading my .bashrc.
But obviously rpm was not overwriting the old file, for whatever reason.
Next bugreport?
Comment 5 Peter Sütterlin 2018-03-19 15:45:56 UTC
Just to confirm:

I repeated the test on the second machine.  I edited /etc/bash.bashrc, bu adding a comment.  Then I forced a re-install.

The comment was still in the file, there was no error reported, and no /etc/bash.bashrc.rpmnew created.
Comment 6 Dr. Werner Fink 2018-03-19 16:51:45 UTC
(In reply to Peter Sütterlin from comment #5)
> Just to confirm:
> 
> I repeated the test on the second machine.  I edited /etc/bash.bashrc, bu
> adding a comment.  Then I forced a re-install.
> 
> The comment was still in the file, there was no error reported, and no
> /etc/bash.bashrc.rpmnew created.

You may also add the set -x in /etc/profile ... see line 329 ff in this file. At login the standard is /etc/profile and not /etc/bash.bashrc
Comment 7 Peter Sütterlin 2018-03-20 06:56:12 UTC
(In reply to Dr. Werner Fink from comment #6)
> (In reply to Peter Sütterlin from comment #5)
> > Just to confirm:
> > 
> > I repeated the test on the second machine.  I edited /etc/bash.bashrc, bu
> > adding a comment.  Then I forced a re-install.
> > 
> > The comment was still in the file, there was no error reported, and no
> > /etc/bash.bashrc.rpmnew created.
> 
> You may also add the set -x in /etc/profile ... see line 329 ff in this
> file. At login the standard is /etc/profile and not /etc/bash.bashrc

Well, the issue above was not directly about whether bashrc is read or not, but rather that a file of an rpm package does neither get installed, nor backed up or flagged as a failure.  
I'd call that a bug, no?  It has just %config /etc/bash.bashrc in the spec file, so it *should* get overwritten (as is also indicated in the comments of the file).
Comment 8 Dr. Werner Fink 2018-03-22 13:28:08 UTC
(In reply to Peter Sütterlin from comment #7)
> (In reply to Dr. Werner Fink from comment #6)
> > (In reply to Peter Sütterlin from comment #5)
> > > Just to confirm:
> > > 
> > > I repeated the test on the second machine.  I edited /etc/bash.bashrc, bu
> > > adding a comment.  Then I forced a re-install.
> > > 
> > > The comment was still in the file, there was no error reported, and no
> > > /etc/bash.bashrc.rpmnew created.
> > 
> > You may also add the set -x in /etc/profile ... see line 329 ff in this
> > file. At login the standard is /etc/profile and not /etc/bash.bashrc
> 
> Well, the issue above was not directly about whether bashrc is read or not,
> but rather that a file of an rpm package does neither get installed, nor
> backed up or flagged as a failure.  
> I'd call that a bug, no?  It has just %config /etc/bash.bashrc in the spec
> file, so it *should* get overwritten (as is also indicated in the comments
> of the file).

NO ... as /etc/bash.bashrc will source /etc/bash.bashrc.local if avaible, the same for /etc/profile with /etc/profile.local
Comment 9 Dr. Werner Fink 2018-05-14 06:33:30 UTC
This open should be fixed with

* Mon Apr 09 2018 werner@suse.de
- Update to version 84.87+git20180409.04c9dae:
  * In bash.bashrc move ssh/sudo source of profile to avoid removing
    the `is' variable before last use (boo#1088524).
  * Avoid the shell code checker stumble over `function' keys word
    in ls.bash (git#54).
Comment 10 Peter Sütterlin 2018-05-15 14:23:05 UTC
Hmm, not really sure what kind of info is requested :o

I had already solved the issue by forcing the install of the bash.bashrc that belonged to the installed aaa_base packet and don't even have the old version around anymore.  The installed version has timestamp April 9, so it looks like the update has been successful, too.

Bug closed.