On Mon, May 11, 2009 at 02:52:43PM -0400, Jerry Feldman wrote:
> Just to add to this a bit. To inherit these changes, you would need to  
> initiate a login shell. The way X works, is that it sets itself up to be  
> the login "shell", and any process executed from X, is essentially a  
> subprocess or subshell. 

It's a small point, but I would actually prefer to say that X is more
like /bin/login -- X does not, for example, typically source the
user's shell rc files, which a login shell normally always does.  

I make this point because this behavior of X is somewhat problematic,
as it turns out... For example, if the user wants to use a different
locale (i.e. $LANG environment variable) than the system adminstrator
has configured as the system default, the first opportunity the user
has is to have the shell change it upon login, by reading the
information from the user's .bashrc, .profile, or similar.  On most
modern Linux systems that I've looked at, X does not normally read the
user's rc files.  What this means is, if the user has set their locale
to be something like ko_KR (EUC-KR-encoded Korean) but the system
default is set to UTF-8, then terminal windows launched by programs
started by the X control program (usually the user's window manager)
will be started with a UTF-8 locale, while programs started by the
user's shell will be started with an EUC-KR locale, and most probably
the user will not be able to read anything on their terminal. :(

Because the user's shell can be anything, I think there's not really a
good solution to this problem.  I have encountered similar problems on
my workstations related to internationalization...  Because my default
shell is bash, and /bin/sh is bash on my systems (forcibly, whenever
I'm on a debian-based system), I generally work around this problem by
editing /etc/X11/xinit/Xsession and having it source $HOME/.bashrc if
that file exists.  But this is not a good solution in the general
case...  If the user has switched from bash to some other shell, that
file may well be out of date; or if the user doesn't use bash, it may
simply not exist.  In either case, that work-around breaks.

I think the best solution would be for the X login manager to exec the
user's shell as a login shell, and then have it exec the Xsession
start-up script.  But it seems that some shells only act as login
shells if the only argument passed to it is '-l' which means that you
could not also have it exec another program via the command line...

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.