Bug 177258

I can't confirm this after a SSH login:

robert@tux:~ > echo $PATH
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/robert/bin
robert@tux:~ > 

robert@tux:~ > grep PATH .bash*
.bash_profile:PATH=$PATH:$HOME/bin
.bash_profile:export PATH
robert@tux:~ >

Actually it works when logged on the CLI, not when opening a gnome-term on the GUI

Please clarify: which situation does bash *not* read .bash_profile in, when it
ought to?

Only login shells should read .bash_profile, and a gnome-terminal shell is not a
login shell unless you enabled the check-button in the preferences.

well, gnome-term is not really useful if PATH or other shell env vars are not
initialised properly. The default .bash* files seem to say this initialising
belong in  .bash_profile.

I guess what you mean is the behaviour change problem is a gnome-term problem
not a bash one. Please confirm so I can reassign the boog.

As far as I can tell, everything is working correctly: gnome-terminal has an
option for whether the shell should be a login shell, and defaults to off; bash
reads .bash_profile when invoked with -l (for example).

Is the observed symptom a *change* in behaviour?  The summary seems to suggest
so.  If so, when was the behaviour any different?

It's a change in behaviour. It's a new account, so maybe I had manually checked
the gnome-term option before

I would argue in this case the default is wrong as it's not "just working"

But that's a gnome problem not a bash one

To add my 2cents worth....the PATH is picked up from /etc/bashrc in konsole
under KDE. However, startkde sh script is not picking up the correct PATH
from bashrc or profile but assigns a default path instead. I have applications
that have their bash shell windows (e.g. IDE's) that do not have access to my
path, which contains additional directories.

If the behavior is changed, what way? Do we need to add a flag to #!/bin/sh
to execute profiles?

I field a bug separately with KDE for this, since it used to work before.

Hi guys,

this was a result of a gdm upgrade, where we switched Xsession files from Fedora
specific to upstream.  The Fedora Xsession file executes things in a login shell
which causes the profiles to execute on login.  The upstream gdm Xsession file
just sourced ~/.profile but didn't execute a login shell.

I switched back to the Fedora Xsession file today.

*** Bug 174653 has been marked as a duplicate of this bug. ***

*** Bug 173438 has been marked as a duplicate of this bug. ***

This did not work for kdm. The startup sequence must be different. If I put
the PATH into /etc/profile.d/lang.sh file then is it picked up correctly.

Hi Sammy,

Can you file a new bug against kdebase explaining your problem?

Thanks.

*** Bug 173936 has been marked as a duplicate of this bug. ***

I have filed a bug against kdebase already before this bug but did not
hear anything yet.

Hi Sammy,

Great thanks! Can you mention the bug number of that report on this report?

Yes, it is:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177130

Thanks

now we are dealing with a bash bug?  With the full path (ie: $SHELL) it doesn't
seem to load the profile..

toppk@one:~ (0)$ exec -l /bin/bash  -c /bin/bash
toppk@one:~ (0)$ exec -l bash  -c /bin/bash
Loading .bash_profile
toppk@one:~ (0)$ 

Yup, there's a bash bug there.  It looks like a few other shells get it wrong,
too, though.  We probably need to come up with a workaround in xorg-x11-xinit.
Reopening and assigning to xorg-x11-xinit.

So Tim fixed this in bash-3.1-5 to work again (should be available in tomorrow's
rawhide).  Other shells that are broken still need to be fixed, but this should
make things better for most users.

Yes, this is fixed (I downloaded and built 3.1-5) BUT I am having yet
another problem:

When logged in as KDE user (should not matter), I do a ctrl+alt+F1
to switch to a text console and login to my account. Unfortunately,
login hangs until I hit ctrl-c, which then gives me the prompt:

              -bash-3.1

Yes, starts with "-". Can anyone confirm this?

Hi,

sounds like a bug in the fix.  Can you file a new bug against bash and report
the bug number here?

*** Bug 177130 has been marked as a duplicate of this bug. ***

Sammy: please file a separate bug report and put in your text from comment #20.

AFAICS after recent updates to FC5t3 the problem is back.  If this is really
a responsibility of bash then this is with bash-3.1-6.2 package.

[root@cyberelk /]# shopt | grep login
login_shell     off
[root@cyberelk /]# sh -c 'exec -l /bin/bash -c shopt' | grep login
login_shell     on
[root@cyberelk /]# rpm -q bash
bash-3.1-6.2

So bash is still correctly becoming a login shell when it sees '-/bin/bash' in
argv[0].

Do you see different results from that command?

Results, which I am seeing, from commands in comment #25 are exactly the same.
Still on a desktop ~/.bash_profile is not processed with effects like in the
original report.

'gnome-terminal' does not have '--login' option anymore and it hardly looks
like the right place to be responsible for that. 'xterm -ls' will run
~/.bash_profile but this is clearly not the answer.  What is more
'gnome-terminal' opened from inside 'xterm' does not inherit its environment.
Is this the real bug?

I don't know how this works beyond the shell.

rstrode/mharris: is this a GNOME problem, or an Xsession problem?

Check to see if /etc/X11/xdm/Xsession is the generic X11 one or the longer
RedHat one that refers to various sessions. It is probably the generic one.
Gnome/KDE have to point to another Xsession in xinit (in KDE), if
you look under /etc/kde/kdm logical links, and /usr/share/config/kdm link.
If any of these is broken/altered than Gnome/KDE will not use the right
Xsession that executes the login shell. This happened to me at some point
when xdm package was updated but then it got fixed by the maintainers of
Desktops, I think!

> Check to see if /etc/X11/xdm/Xsession is the generic X11

It looks like a "generic" one.  It is from xorg-x11-xdm-1.0.1-1.2
and 'rpm -V xorg-x11-xdm' does not have anything to report.

> If any of these is broken/altered than Gnome/KDE will not use the right
> Xsession that executes the login shell.

It seems that there is a problem here.  How is /etc/X11/xdm/Xsession to
know what is my login shell?  It happens to be bash at this moment but it
does not have to be.

To quickly see if this is the problem find the other Xsession e.g.
from /etc/X11/xinit directory and copy it to /etc/X11/xdm directory
(save Xsession there first). Restart X and possible gdm/kdm again
and see if it all works.

what does cat /etc/gdm/custom.conf /usr/share/gdm/defaults.conf | grep -i xsession

say?

(In reply to comment #27)
> I don't know how this works beyond the shell.
> 
> rstrode/mharris: is this a GNOME problem, or an Xsession problem?

Comment #8 suggests it is a gdm bug.  To the best of my knowledge, the
FC5 files are identical to the FC4 and earlier ones modulo bugfixes and
whatnot.  I don't believe anything has changed in the xdm/xinit scripts
or configs between FC4 and FC5 which would cause this type of problem.

Someone might want to strace through the gdm/X startup perhaps to see
what is happening.

HTH

Mike,

That's not exactly true.  I believe you used to install the system Xsession in
/etc/X11/xdm/Xsession and now install it in /etc/X11/xinit/Xsession. 
/etc/X11/xdm/Xsession now contains an upstream Xsession file.  This change
happened when we went modular.

GDM was updated to point to the new Xsession file, but it's conceivable the old
file is lingering in people's configurations.

I'd recommond deleting /etc/X11/xdm/Xsession in the xdm package and symlink it
to the system Xsession file.

About comment #30.  Replacing /etc/X11/xdm/Xsession with the current
/etc/X11/xinit/Xsession does not help.  They are obviously different but
it is not clear which one is actually used and anyway I do not see there
a code which would process user shell startup.

If I will patch /etc/gdm/Xsession the following way

--- /etc/gdm/Xsession.orig	2006-02-19 00:22:51.000000000 -0700
+++ /etc/gdm/Xsession	2006-02-24 10:53:40.000000000 -0700
@@ -36,7 +36,8 @@ echo "$0: Beginning session setup..."
 
 # First read /etc/profile and .profile
 test -f /etc/profile && . /etc/profile
-test -f "$HOME/.profile" && . "$HOME/.profile"
+test -f "$HOME/.bash_profile" && . "$HOME/.bash_profile" || \
+{ test -f "$HOME/.profile" && . "$HOME/.profile"; }
 # Second read /etc/xprofile and .xprofile for X specific setup
 test -f /etc/xprofile && . /etc/xprofile
 test -f "$HOME/.xprofile" && . "$HOME/.xprofile"

then my ~/.bash_profile is indeed processed.  I did changes of that sort
while waiting for the previous incarnation of this bug to be fixed but
I thought that this is not longer required.  Apparently it still is.
I am not sure what happens if somebody is using, say, kdm instead.
This is with gdm-2.13.0.8-4.

Hi Michal,

What if you replace /etc/gdm/Xsession with the current /etc/X11/xinit/Xsession ?

We aren't supposed to be shipping /etc/gdm/Xsession. I'll fix it.

Don't you have lines like:

exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH gnome-session"

in your /etc/X11/xinit/Xsession file? The whole thing is working
for KDE which used these files so the problem cannot be bash. Are
there other gnome users having the same problem?

Well, yes, replacing /etc/gdm/Xsession with /etc/X11/xinit/Xsession looks
like it works - regardless of what is in /etc/X11/xdm/Xsession.  Too many
of these Xsession files are floating around. :-)

Yes, there is a line

       exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH gnome-session"

in /etc/X11/xinit/Xsession but clearly this is not what is really executed
in a default setup.

Just removing /etc/gdm/Xsession in the current situation is not the answer.
There is "BaseXsession=/etc/gdm/Xsession" reference in /etc/gdm/custom.conf.
One could change that, of course to point to /etc/X11/xinit/Xsession and
then shell startup files are processed, not that surprisingly, too.

I am not sure what to do with /etc/X11/xdm/Xsession.  It appears that this
better be a link to /etc/X11/xinit/Xsession as well.

Michal,

In the default setup BaseXsession=/etc/X11/xinit/Xsession.  Have a look at
/usr/share/gdm/defaults.conf.

The gdm package was *supposed* to delete its Xsession file and just create a
symlink to the system one in the off chance someone whos been following rawhide
over the last few months had BaseXsession=/etc/gdm/Xsession in their config
file.  It did this for a few releases, but I broke it when I moved gdm from
/etc/X11/gdm to /etc/gdm (I forgot to change /etc/X11/gdm to /etc/gdm in a few
places in the spec file).

Should be fixed in tomorrow's rawhide, but Mike should still fix xdm though.

> In the default setup BaseXsession=/etc/X11/xinit/Xsession.

Good to know but something in recent series of updates rewrote
/etc/gdm/custom.conf; or at least it changed timestamp there.  I was not
that pleased as no original was left and I could not check what was changed.
What is more, I am pretty sure that before these updates /etc/gdm/Xsession
was not there.  If not that detail that it showed back I could have catch
up what is the real culprit sooner.

BTW, are two copies of this file in /usr/share/gdm/ really needed?
defaults.conf and factory-defaults.conf do not differ.

This is fixed for me now in gdm 2.13.0.8-5, but I manually changed the
/etc/gdm/Xsession symlink to "/etc/X11/xinit/Xsession" instead of
"../xinit/Xsession" (I guess RPM doesn't change symlinks?)

> This is fixed for me now in gdm 2.13.0.8-5 ...

# rpm -q gdm
gdm-2.13.0.8-5
# rpm -qlv gdm | grep Xsession
 ......   17 Feb 24 12:15 /etc/gdm/Xsession -> ../xinit/Xsession

This is a wrong link.  It should be to ../X11/xinit/Xsession or you are
ending up with a dead link in /etc/gdm if Xsession was not there.

I just edited 'BaseXsession' in custom.conf to point to the right one and
which seems like a more reliable way.  Postintall edits this file anyway.
At least this is done:

if [ $1 -ge 2 ]; then
   sed -i -e 's@/etc/X11/gdm@/etc/gdm@g' /etc/gdm/custom.conf
fi

while this _really_ should be

if [ $1 -ge 2 ] && grep -q /etc/X11/gdm /etc/gdm/custom.conf ; then
   sed -i -e 's@/etc/X11/gdm@/etc/gdm@g' /etc/gdm/custom.conf
fi

to avoid spurious edits and time-stamp changes when none is needed.

Other edits are weird too.  Instead of one sed call with multiple actions
there is there a huge pile of separate sed calls each one rewriting the same
file in place and considerably raising a chance that something will go wrong.

Admitedly this happens only if there is /etc/X11/gdm/gdm.conf to migrate
but then why not simply

 sed "all actions here" /etc/X11/gdm/gdm.conf > /etc/gdm/custom.conf

And after all of that we clobber results with a copy of
/usr/share/gdm/config/gdm.conf-custom if we find one.  Hm ....

> I guess RPM doesn't change symlinks?

Packages are unpacked with cpio and cpio will not clobber an existing file
with a symlink; but it is possible in %pre script to move, if it exists,
/etc/gdm/Xsession to a backup file and then a symlink will show up.  Make
sure that it is to something which does exist.

Hey guys, 

I fixed the broken symlink this morning.  It should be moved into rawhide
sometime this weekend.

Could you file separate bugs about the other spec file clean ups?