Adam Siepel wrote: > permissions look good. > > [acs@newton acs]$ ls -l ~/.xsession > -rwx------ 1 acs acs 60 Jun 7 08:59 /home/acs/.xsession* Seems reasonable enough. I am not that restrictive myself. (But people at work want to be able to copy my files. :-) > I must be missing something here. If the .xsession is executed, rather > than sourced, why would the environment be inherited anyway? The environment is inherited by the children of a process. If it is run with /bin/sh then it won't be a login shell and it won't read your .profile or .bash_profile. So it won't get your custom environment. As '#!/bin/bash --login' the bash will be told it is a login shell. It will read your ~/.bash_profile. When *that particular bash* starts up the window manager that window manager will be a child and will inherit the environment. > [acs@newton acs]$ cat .xsession > #!/bin/sh > > export XSESSION_READ=true > source ~/.bash_profile That is invalid syntax for a /bin/sh shell. The /bin/sh shell is a POSIX shell. There are several valid candidates. One is bash and in that case (which is what you are undoubted seeing) it will work. (Almost. Not if you source bash_completion in your profile.) But if you replace /bin/sh with one of the other candidates then it will probably not work since 'source' is not a valid syntax. And also you may have bash specific syntax in your .bash_profile which a posix shell won't parse the same as bash. Most importantly you are not starting up a window manager there!? Which is the whole point of the ~/.xsession file. You may find reading through the default startup scripts /etc/X11/Xsession* useful to understand this process. The very last line is 'exec $STARTUP'. The 'exec' overlays and replaces the current process with the new one. That new process will inherit the environment of the parent process. > [acs@newton acs]$ sh .xsession > [acs@newton acs]$ echo $XSESSION_READ > <nothing> > [acs@newton acs]$ source .xsession > [acs@newton acs]$ echo $XSESSION_READ > true > > Do I need to explicitly start my window manager in .xsession so it's a > subprocess? I guess it's currently getting started somewhere else... Yes! Exactly! Assuming bash, here is one example ~/.xsession. #!/bin/bash --login exec x-session-manager # or fvwm or startkde or gnome or whatever This way the window manager is a child of #!/bin/bash, which read your ~/.bash_profile, set your variables, then started up your window manager. It must be executable or the #!/bin/bash is only a comment. Bob
Attachment:
pgp2igzNZet4L.pgp
Description: PGP signature