Re: Problems starting emacs with correct environmental settings

[Tim X <timx@nospam.dev.null>]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 03.07.2009 um 12:08 schrieb Pascal J. Bourguignon:
>
>> Depending on the shell used by these scripts, you may edit one of the
>> file used by these shell to set the environment. Eg. in case of bash,
>> you could set your environment in ~/.bash_env or ~/.bash_login or
>> ~/.bashrc ; for other Bourne shells, ~/.profile or ~/.login could be
>> used.  In the last resort, you can directly edit the X startup scrip
>> that is used in your configuration.
>
>
> Alain send me some answers privately. To me it seems that processes created
> from the menu icons inherit only a small environment, could  be that of a
> privileged process. It obviously has some basic  components in PATH, but
> not Alain's private parts. And GNU Emacs  actually is opened via
> emacsclient, from a shell script, which is  passed to the launcher as "
> ~/..." and "~/" does not get expanded to  something like "/home/<user>/..."
>
> With pstree, observing such a launched process, one might find some basic
> clues. By using a shell script that creates a login shell to  launch
> emacsclient from inside it a few problems could be cured…
>
> --
> Greetings
>

Note that I'm speaking about accessing X from gdm/xdm/etc rather than
starting it with something like startx.

On modern Linux boxes, the scripts that start X do so in a non-login
shell. This means files like .bash_profile are not sourced. The X
session is normally run as the last stage in the startup process - often
the last line is something like

exec <window manager> 

which makes the current running process your X window manager
process. When you kill that process, you are logged out. 

The limitation of this approach is that your X window manager process
does not have all the environment settings that you would normally see
in a standard login shell. When the window manager forks another process
to launch something like emacs, it passes on its environment variables,
but as its not a login shell and .bash_profile has not been sourced, the
envrionment is somewhat limited. 

There are  a number of solutions you can use.

1. In the case of GDM, edit /etc/gdm/Xsession and make it either run as
a login shell or have it source your .bash_profile etc. 

2. Write a shell wrapper script which sources your environment scripts
and use it to launch programs from menus/icons etc. 

3. Start an xterm witht he -ls switches so that it starts as a login
shell and execute the programs from there. 

4. You can set some environment settings in the /etc/environment file,
but note that all processes source this file, including processes that
are not started by a specific user.

I use to change the first line of the Xsession script so that it runs as
a login shell and then I have all my environment settings. However, I
stopped doing that because everytime GDM was updated, I'd lose my
changes if the update included a new Xsession script. 

Now, I place settings that are common to all users/processes in
/etc/environment and I have a basic 'launcher' script that sources my
.bash_profile before starting a program like emacs. I use this script in
place of the standard things for opening an xterm or starting emacs. 

HTH

Tim

-- 
tcross (at) rapttech dot com dot au