Feature Request: Provide a single configuration file for user settings

Bug #134378 reported by Philipp Kohlbecher
6
Affects Status Importance Assigned to Milestone
Ubuntu
Invalid
Wishlist
Unassigned

Bug Description

I want to set a number of environment variables on login (LC_* and PATH, for example). I want these settings to take effect regardless of whether I log in through gdm or the virtual console.

I do not think that there is a single configuration file in my home directory that gets sourced on both types of login.
(I know that I could work around this by including something like "source my_configuration_file" in both .gnomerc and .bash_profile.) I would be nice to have a single file to store such settings. Ideally, it would be sourced irrespective of the shell I use.

Obviously, this is not an issue with ubuntu specifically--as far as I know, all Linux distributions have this problem.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it. We appreciate the difficulties you are facing, but it would make more sense to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs.

You may find informations about your particular problem at https://help.ubuntu.com/community/EnvironmentVariables

Thanks.

Revision history for this message
Philipp Kohlbecher (xt28) wrote :

Thank you for taking the time to answer this issue. Examining the answer you have given me, this does not appear to resolve the issue, though...

I assume you refer to the following in https://help.ubuntu.com/community/EnvironmentVariables:

"In order to set environment variables in a way that effects a user's entire desktop session, one may place commands to set their values in one of the "hidden" script files in the user's home directory. The more common such files are outlined below.

      ~/.profile - This is probably the best file for placing environment variable assignments in, since it gets executed automatically by the DisplayManager during the startup process desktop session as well as by the login shell when one logs-in from the textual console. "

This would indeed resolve this issue, if only it were true. gdm does not, in fact, execute ~/.profile.

Since this differs from expected and documented behaviour, I am reopening this bug and assigning it to gdm.

Thanks.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Setting back to incomplete due to your last comment.

Indeed, $HOME/.profile and /etc/profile are what you're looking for.

These files are sourced from /etc/gdm/Xsession (.gnomerc has been deprecated a while ago) and read by your login shell. (From sh man page "A login shell first reads commands from the files /etc/profile and .profile if they exist.") All environment variables set in these files will be available whether you're logging in through gdm or a virtual console.

- Please, can you describe the steps to follow to reproduce your issue ?
- Can you provide the output of the command "lsb_release -rd"
- Can you provide the output of the command "apt-cache policy gdm"
- Can you provide the value of the shell returned by "getent passwd $USER" when logged in with the user with this issue.

Thanks in advance.

Revision history for this message
Philipp Kohlbecher (xt28) wrote :

Ah, I see where I went wrong.

Environment variables set in ~/.profile need to be exported in order to be present in x-session-manager and all its descendants. (Whereas they will be present in login shells even when they are not exported.) The line 'PATH=~/bin:"${PATH}"' (no export) and the fact that everything worked as expected when logging in on the virtual console made me think that those variables did not need to be exported.

After adding the appropriate "export" commands everything works fine.

Sorry for bothering you and thanks for your efforts!

Revision history for this message
Daniel Hahler (blueyed) wrote :

Thank you for reporting back, Philipp.
Closing as "invalid" again.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.