[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "source" shell commands
From: |
Tim X |
Subject: |
Re: "source" shell commands |
Date: |
Mon, 26 Mar 2007 21:30:45 +1000 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux) |
Matthew Flaschen <matthew.flaschen@gatech.edu> writes:
> Tim X wrote:
>> The simplest solution I've found is to change the Xsession script that sets
>> up
>> your session to be a bash login shell - then ~/.bash_profiel (or ~/.profile)
>> will get sourced prior to the window manager being started and everything
>> that
>> is then spawned by the window manager (using menus, 'run' boxes or start
>> icons)
>> will inherit the users login env.
>
> I'm sorry. I don't understand what you mean here. Exactly what would I
> have to modify to do this?
>
Its difficult to be precise as things differ depending on the setup you have
and the display manager you are using. However, essentially, xdm and gdm, two
of the main display managers, have a script called (usually) Xsession. On many
systems, including Debian (and I therefore suspect Ubuntu) this script is not
run as a login script and is normally a /bin/sh script rather than /bin/bash.
As it is not run as a login script, it doesn't source your ~/.profile (or
~/.bash_profile. This script also usually sources the client startup scripts
(either the system default ones or a 'customized' one which is usuallyy called
~/.Xsession or ~/.xsession. Under debian, if you have a .Xsession script, that
will be executed instead of the system defaults. (What determines exactly what
is executed is usually selected from a menu on the display manager login
screen. Common entries are "Failsafe", "Default", "Gnome", "Last Session" etc).
Usually the last entry in the client script sourced by the system Xsession
script is something like
exec window_manager
which means the window manager process inherits the process the Xsession script
was running in. Once the window manager process exits, your X session exits and
control returns to the display manager.
If the Xsession script is not running as a login shell and it has not sourced
your environment settings in ~/.profile (or whatever), none of these settings
are in effect for the window manager or any processes it spawns (such as when
you start an aplication from a menu). To fix this problem, you need to have
your .profile sourced *before* the window manager starts. The easiest way to do
this is to change the Xsession script to run as a login shell. On Debian, this
can easily be achieved by changing the first line from
/bin/sh
to
/bin/bash --login
The script will then source yor startup files before it starts executing and
the window manager will inherit this environment. As environment variables are
exported to sub shells, etc, anything that is started from within the window
manager will inherit all of these environment variables.
As mentioned in an earlier post, my system is heavily customized, so I'm
working from memory a bit regarding exactly which file to change. It also
depends on the display manager and I'm not familiar with KDE, so I can't be
precise as to exactly which file it would be, but the basic principle is the
same - find the script that sources the session setup scripts and/or runs the
window manager and make it a login shell rather than just a normal shell.
For xdm I think the file is in /etc/X11/xdm/Xsession and for gdm I think the
file is /etc/gdm/Xsession. (Note that Debian also has an /etc/X11/Xsession and
an /etc/X11/Xsession.d directory of files. These are *not* the ones you need to
change.
HTH
Tim
P.S. Years ago, when I first started using X windows (late 80s), things were
somewhat simpler. The user would have an .Xsession file that contained all the
startup stuff they wanted done and then do an exec at the end to start the wm.
Then things changed to make it easier to maintain a default setup rather than
require the user to manage it. At this time, the default was to run things as a
login shell. This later changed and I've never really found out why. There is
probably a god reason and possibly there are some issues with doing this, but
I've never had a problem in 20 years (maybe I'm just lucky).
PPS Another thing you could try which may work is if your system has a
/etc/X11/Xsession.d directory, you could try dropping a new file in there which
just sources the user's ~/.bash_profile or ~/.profile. While this may work
fine on a single user box, it could cause issues on a multi-user system as not
everyone runs bash as their login shell.
--
tcross (at) rapttech dot com dot au
- Re: "source" shell commands, (continued)
- Re: "source" shell commands, Matthew Flaschen, 2007/03/24
- Re: "source" shell commands, Matthew Flaschen, 2007/03/24
- Re: "source" shell commands, Peter Dyballa, 2007/03/25
- Re: "source" shell commands, Matthew Flaschen, 2007/03/25
- Re: "source" shell commands, Peter Dyballa, 2007/03/25
- Re: "source" shell commands, Matthew Flaschen, 2007/03/25
- Re: "source" shell commands, Peter Dyballa, 2007/03/26
- Re: "source" shell commands, Matthew Flaschen, 2007/03/26
- Message not available
- Re: "source" shell commands, Tim X, 2007/03/25
- Re: "source" shell commands, Matthew Flaschen, 2007/03/25
- Message not available
- Re: "source" shell commands,
Tim X <=
- Message not available
- Re: "source" shell commands, Tim X, 2007/03/24
- Re: "source" shell commands, Matthew Flaschen, 2007/03/25
- Message not available
- Re: "source" shell commands, Tim X, 2007/03/25
- Message not available
- Re: "source" shell commands, Tassilo Horn, 2007/03/26
- Re: "source" shell commands, Matthew Flaschen, 2007/03/26
- Message not available
- Re: "source" shell commands, Tassilo Horn, 2007/03/26
- Re: "source" shell commands, Matthew Flaschen, 2007/03/26
Re: "source" shell commands, Tim X, 2007/03/24