Bug 32408 - Logging in via (x|g|k)dm does not source /etc/profile
Summary: Logging in via (x|g|k)dm does not source /etc/profile
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinitrc
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: Aaron Brown
URL:
Whiteboard:
: 35935 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-03-20 16:43 UTC by monnier+lists/redhat/bugs
Modified: 2007-04-18 16:32 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-07-13 19:59:42 UTC
Embargoed:


Attachments (Terms of Use)

Description monnier+lists/redhat/bugs 2001-03-20 16:43:42 UTC
When a user logs in via gdm, xdm, kdm or somesuch display manager,
the user's shell is not started as a login shell, which implies that
/etc/profile and ~/.profile (or ~/.bash_profile or whichever file the
shell uses for that purpose) is not sourced.
In turn this introduces problems because environment variables
are not properly intitialized at login time.

/etc/X11/xdm/Xsession should not do

	exec gnome-session
but
	LoginExec () {
	    exec - "$SHELL" <<ENDDOC
	       $*
	ENDDOC
	}
	LoginExec exec gnome-session

(the `exec -' might need to be turned into `exec -l' for bash-2.0).

Comment 1 Mike A. Harris 2001-03-22 01:17:28 UTC
This is not a bug.  If you're using xterm, or similar, if you want it to start
a login shell, read the manual pages for it, and add the parameter to force
a login shell.  This will source all the files necessary.  This is not a bug.
For xterm, I believe it is "xterm -ls".

Comment 2 monnier+lists/redhat/bugs 2001-03-22 01:30:42 UTC
I'm quite aware of the `xterm -ls' thingy, thank you, but I'm not talking
about xterm here.  I'm talking about setting up the environment that will
influence the behavior of *all* the applications the user will use, including
those started from a menu or a application-dock or a control-panel or whatever
you call it these days.  No interactive shell in sight.

Things like MANPATH, PATH, LANG, CVSROOT, ...

The standard way to do it (for all but XDM logins) is to set it up
in /etc/profile (for site-wide effect) or ~/.profile (of course, the
files are different for different csh and other shells).  There is no
good reason why XDM should be an exception here.  Especially since there
is no good replacement for it when using XDM.  F.ex. where do *you*
put such setups ?

How many times do you hear complaints on some newsgroup that "foobar
works from an xterm but not from the menu" and variants thereof ?

Comment 3 monnier+lists/redhat/bugs 2001-04-04 03:46:08 UTC
I believe your claim "it's not a bug" is clearly not backed
by any convincing explanation since you presumed that I was using
some kind of terminal emulator, which I'm not.

Files like .login, /etc/profile , etc... are used to setup
the session's environment, not some specific shell's environment
and should thus be sourced whenever a session is started.


Comment 4 Mike A. Harris 2001-04-09 21:14:24 UTC
To be honest with you, I have not heard _anyone_ claiming that any program
on the GNOME or KDE menu fails due to the claims you are making.  There
*may* be a problem perhaps.  I have *yet* to see from you a specific
example of an application that fails because of your claim.  If you can
provide me with a few SPECIFIC and easily reproduceable cases of this
problem, then I will indeed test them and discuss it with others here and
most likely come up with a solution.

If this is indeed a generic bug with xdm/kdm/gdm, I would think I would have
heard more about it by now...  however, I suspect it is only an xdm problem,
which is the only explanation I can think of for why I haven't heard anyone
else mention anything as practically nobody uses xdm anymore.

So... if you can give me a test case (preferably involving software that is
part of the OS or powertools), but not necessarily - then I will try to
reproduce it, and then possibly fix it if it does indeed misbehave.

Comment 5 Alex Kanavin 2001-04-13 18:10:11 UTC
First of all, I fully agree with the person who opened this bug: profiles should
be _ALWAYS_ set up on logins be they graphical or text ones.
As for an example of problems that arise when that does not happen, look at the
LANG environment variable that
is set up from Red Hat supplied /etc/profile.d/lang.sh. Setting this variable
(in /etc/sysconfig/i18n) is absolutely vital to anyone who wishes 
to use any language or locale other than english. Another example is PATH, where
$HOME/bin does not get appended because of this. Etc, etc, etc.
For a full list of things that are set up (by Red Hat distribution itself!) in
profiles please look at /etc/skel/.bash*, /etc/profile and /etc/profile.d/*. 

And then there are user's custom profile settings that do get ignored because of
this. Log in via xdm, issue 'set' command and see for yourself!

Also, I'm not suggesting a fix, because the fix above is very good. All exec's
in /etc/X11/xdm/Xsession should be replaced in this way.
Integrate it into the distribution please!



Comment 6 Alex Kanavin 2001-04-13 18:19:20 UTC
Also, you won't see this behaviour with gdm, because gdm executes Xsession
itself with an '-' flag!
Thus all profiles do get set up. But that's a hack, and it should go away (in my
opinion).

As for kdm, whether or not profiles are set up, depends on what session you're
running:
in failsafe they don't, in kde they do (because kde itself sets them up
somewhere, not sure
where exactly). This kde behaviour is a hack too and should go away as well :-)



Comment 7 monnier+lists/redhat/bugs 2001-04-13 18:27:01 UTC
I didn't know that GDM had such a hack.  I agree that it's not satisfactory
becuase it only works if your login shell is the same as the shell used
to write the Xsession file.  If you r shell is tcsh, your .login file
won't be sourced (and the .bash_login will instead).


Comment 8 Alex Kanavin 2001-04-14 07:54:46 UTC
Well, it seems gdm tries to run Xsession with user's login shell. 
But according to bug #7860 this does not work - bash profiles 
are always executed. 


Comment 9 Alex Kanavin 2001-04-30 10:34:29 UTC
Bug #35935 has a discussion of the same problem.
It's not about running login shells in terminal emulators as Red Hat people seem
to think.
It's about setting up system-wide and user profiles on *dm logins that currently
depends on what *dm and what graphical environment you happen to use.

Comment 10 Havoc Pennington 2001-05-19 22:34:11 UTC
*** Bug 35935 has been marked as a duplicate of this bug. ***

Comment 11 Mike A. Harris 2001-05-20 05:10:34 UTC
Ok, relax guys... it is just a bug, not the end of the world.  ;o)
I did not understand the problem, and wasn't about to go randomly
changing things that I wasn't sure of that will affect millions of
users.  I wanted a "why" explanation and I have gotten one now.  I
think the request is reasonable, and will do something about it. No
need to get all worked up over it.  Think good positive thoughts now,
knowing that you have helped whack a clue about X startup into my head.  ;o)
I don't use xdm/kdm/gdm so I'm rusty with that stuff.  I will likely make
this change along with numerous other change requests similar all at the
same time at some point.

Just so bero and hp know, when this change occurs, the Gnome and KDE startup
may be affected.  Note to self - "remind you guys later".  ;o)

Comment 12 LENHOF 2001-07-13 19:59:38 UTC
Hi guys,

It could be nice to see the profile of user to be completely sourced with the
same convention used on Solaris...

Indeed if in .dt_something_ there's a variable called DTSOURCEPROFILE which can
be true or false (default to true)....

Like this if a user haven't have a bash login (some user of computers I make the
administration have csh....or tcsh.....) it could have his profile sourced...

I think you have to modify /etc/X11/xdm/xsession to make it work....

Just my 2 cents

JY

Comment 13 Mike A. Harris 2001-08-20 03:46:59 UTC
Been fixed for a while now in Rawhide.  Will be in final release
of RHL 7.2.


Note You need to log in before you can comment on or make changes to this bug.