Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 7221 - ".profile" files are not executed for non-bash shells under X window
Summary: ".profile" files are not executed for non-bash shells under X window
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdm
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Elliot Lee
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-22 10:34 UTC by John Horne
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-05-24 20:06:36 UTC


Attachments (Terms of Use)

Description John Horne 1999-11-22 10:34:03 UTC
I use the Korn shell (pdksh) by default. I also run my ssytem at init level
5 by default. I use KDE by default.
However, the ".profile" file in my home directory does not get executed
at login. Under RH5.2 (from which I upgraded) it did. I have tried this
with the 'ash' shell as well and got the same result. Bash does not
have this problem. Running the system at init 2 or 3 it all works okay.

It seems that bash and Csh have special handling for the login scripts -
hence no problem with them. However, for any other shell combined with
X window being run by default, ther eis nothing saying to execute a
.profile
file in the users home directory.

Under RH5.2 the file /etc/X11/kdm/Xsession existed to do this. At 6.1 it
seems that both KDE and gnome run the file /etc/X11/xdm/Xsession.
From 5.2 I have included into this file:

if [ -r "$HOME/.profile ]; then
   . "$HOME/.profile"
fi

The RH5.2 system had an 'else' part to this statement - but I left it ot
since
it was never executed by me (it ran something I don't use).

John.

Comment 1 Chris Siebenmann 1999-11-22 23:30:59 UTC
The current approach for setting up the environment when one logs
in via a graphical login appears to be to start scripts with
	#!/bin/bash -login
and assume that everyone uses bash or something compatable enough,
and writes their login dotfiles nicely, so that 'bash -login' will
work. As you've noticed, this doesn't always fly (especially for
people using login shells, such as tcsh, that don't use .profile et
al at all).

Comment 2 Trond Eivind Glomsrxd 2000-04-06 21:56:59 UTC
Remember to specify that each kterm is to be a login shell - then you'll avoid
the problem

Comment 3 Trond Eivind Glomsrxd 2000-05-09 14:05:59 UTC
This isn't a ksh problem - we are aware of it (and have been so for some time),
and are thinking about how to fix this (not just ksh...). I think gdm is a
better candidate component.

Comment 4 David Mason 2000-05-24 20:06:59 UTC
Elliot - is gdm the answer to this problem? What do you think?

Comment 5 Elliot Lee 2000-07-17 20:09:22 UTC
Since the 'Xsession' script uses 'bash -login', things should be initialized
correctly AFAIK. I don't see any csh- or bash-specific logic other than assuming
that bash can initialize things correctly.


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