Re: [Xquartz-dev] env variables and launchd problem
On Mar 23, 2011, at 7:00 AM, Peter Dyballa wrote:
IMO this should not be necessary, because up to Leopard ~/.MacOSX/ environment.plist is read when you log in. Then all processes inherit this environment. The X clients are a bit different and used to inherit their environment from X11.app ? until recently!
Nope. X11 clients do inherit their environment from X11.app, since that's the process that forks and execs them. That has not changed.
Yes, right! The problem is that X11.app now does not inherit the set environment and passes something not so useful to the X clients. Which needs to be corrected. Particularly the manner to set / als current working directory. $HOME is correct.
Thank you Peter for being the first on the list to answer my question, after a zillion posts on the topic. So the problem is not a config issue on my machine, others are seeing it. This helps me enormously. I am also using ~/.MacOSX/environment.plist as a work-around, to make sure the right ENV gets passed to X11 when it is launched by launchd. I agree with Jeremy that it is not the best solution, just the only one available now. That file passes its ENV to every launchd process, where I really only need it to be passed to X11. Dave
On Mar 23, 2011, at 10:02, Dave Ray wrote:
On Mar 23, 2011, at 7:00 AM, Peter Dyballa wrote:
IMO this should not be necessary, because up to Leopard ~/.MacOSX/ environment.plist is read when you log in. Then all processes inherit this environment. The X clients are a bit different and used to inherit their environment from X11.app ? until recently!
Nope. X11 clients do inherit their environment from X11.app, since that's the process that forks and execs them. That has not changed.
Yes, right! The problem is that X11.app now does not inherit the set environment and passes something not so useful to the X clients. Which needs to be corrected. Particularly the manner to set / als current working directory. $HOME is correct.
Thank you Peter for being the first on the list to answer my question, after a zillion posts on the topic.
Did you miss my response to you? Or did you miss my response to him that his statement is actually incorrect.
So the problem is not a config issue on my machine, others are seeing it. This helps me enormously.
As I mentioned earlier, it has to do with X11.app inheriting a login shell environment from ~/.bash_profile, ~/.bash_login, or ~/.profile ... which means it does not use ~/.bashrc. Non-login shells use ~/.bashrc. If you want your ~/.bashrc used in login shells as well, make sure you source it in your ~/.bash_profile
I am also using ~/.MacOSX/environment.plist as a work-around, to make sure the right ENV gets passed to X11 when it is launched by launchd.
Use ~/.profile (or ~/.bash_profile)... *especially* if you're on Leopard because environment.plist does not get set in LaunchAgents, so if X11.app is forked from /usr/X11/bin/X from /usr/X11/bin/xinit from launchd, you will not have the environment.plist environment, but you *WILL* have your login shell environment.
I agree with Jeremy that it is not the best solution, just the only one available now. That file passes its ENV to every launchd process, where I really only need it to be passed to X11.
Actually, it does *NOT* pass its environment through launchd (on Leopard). --Jeremy
On Mar 23, 2011, at 11:44 AM, Jeremy Huddleston wrote:
Did you miss my response to you? Or did you miss my response to him that his statement is actually incorrect.
I saw your post, but what you are describing is not consistent to what I'm observing on my machine. It's not that I don't believe you, I am just trying to understand why.
So the problem is not a config issue on my machine, others are seeing it. This helps me enormously.
As I mentioned earlier, it has to do with X11.app inheriting a login shell environment from ~/.bash_profile, ~/.bash_login, or ~/.profile ... which means it does not use ~/.bashrc. Non-login shells use ~/.bashrc. If you want your ~/.bashrc used in login shells as well, make sure you source it in your ~/.bash_profile
I never used ~/.bashrc. I never said I did. My /etc/profile, which the shell is correctly invoking, loads /etc/bashrc. This is normal. The /etc/profile that comes with Snow Leopard does this and there is nothing wrong with it. Terminals all have the correct expected env from .etc/bashrc because it is being correctly invoked by /etc/profile. X11 is different.
I am also using ~/.MacOSX/environment.plist as a work-around, to make sure the right ENV gets passed to X11 when it is launched by launchd.
Use ~/.profile (or ~/.bash_profile)... *especially* if you're on Leopard because environment.plist does not get set in LaunchAgents, so if X11.app is forked from /usr/X11/bin/X from /usr/X11/bin/xinit from launchd, you will not have the environment.plist environment, but you *WILL* have your login shell environment.
As I said in my previous posts I am using Snow Leopard. To satisfy your suggestion: if I copy /etc/bashrc to ~/.bash_profile, and/or to ~/.profile, nothing changes. I can have copies of /etc/bashrc in ~/.bash_profile and ~/.profile at the same time and get the same results. That's because this is not the source of the problem. A different env is being passed to X11, even with those files in place. To reiterate, I am starting up X11 with only an xterm and no window manager. I am typing 'env' in that xterm. This where I'm seeing ENV being different from terminals opened normally. This is the only way I can capture the difference in what env is being passed to X11 versus other shells at the terminal. The conditions which give this xterm the correct ENV, are also the same conditions in which problems are absent with my X11 app. This conditions are: either start X11 with 'startx', or add ~/MacOSX/environment.plist.
I agree with Jeremy that it is not the best solution, just the only one available now. That file passes its ENV to every launchd process, where I really only need it to be passed to X11.
Actually, it does *NOT* pass its environment through launchd (on Leopard).
I am using Snow Leopard. Dave
Wed, 23 Mar 2011 (13:04 -0700 UTC) Dave Ray wrote:
To reiterate, I am starting up X11 with only an xterm and no window manager. I am typing 'env' in that xterm. This where I'm seeing ENV being different from terminals opened normally. This is the only way I can capture the difference in what env is being passed to X11 versus other shells at the terminal.
What if you add the following to the X11 Applications menu: Name: Environment Command: /usr/bin/env > /tmp/xenv and select the command 'Environment' from the menu? What do the contents show in /tmp/xenv? Wouldn't that give you the environment that the xserver uses (rather than any environment created for an xterm child process)? -- rdr
robert delius royar wrote:
To reiterate, I am starting up X11 with only an xterm and no window manager. I am typing 'env' in that xterm. This where I'm seeing ENV being different from terminals opened normally. This is the only way I can capture the difference in what env is being passed to X11 versus other shells at the terminal.
What if you add the following to the X11 Applications menu: Name: Environment Command: /usr/bin/env > /tmp/xenv and select the command 'Environment' from the menu?
What do the contents show in /tmp/xenv? Wouldn't that give you the environment that the xserver uses (rather than any environment created for an xterm child process)?
I tried your suggestion. The contents of /tmp/xenv are the same as normal shells, they have my user-modfied path that includes /usr/local/bin. Actually, any X11 terminal that is opened by the Applications menu of X11.app has the ENV from my config file. The xterm that opened at the beginning of the session from .xinitrc.d/99-wm.sh still has the shorter path without /usr/local/bin and is not reading my config. This is with copies of the same bash config file in three places: ~/.profile, ~/.bash_profile, and /etc/bashrc. I'm going to keep those copies in place until I get to the bottom of it. Perhaps what I'm seeing is normal. Is it normal for my bash config not to be loaded at the xterm that is invoked from .xinitrc.d/99-wm.sh ? If so then perhaps the wm I'm testing is not reading its ENV properly. Dave
On Mar 23, 2011, at 14:22, Dave Ray wrote:
robert delius royar wrote:
To reiterate, I am starting up X11 with only an xterm and no window manager. I am typing 'env' in that xterm. This where I'm seeing ENV being different from terminals opened normally. This is the only way I can capture the difference in what env is being passed to X11 versus other shells at the terminal.
What if you add the following to the X11 Applications menu: Name: Environment Command: /usr/bin/env > /tmp/xenv and select the command 'Environment' from the menu?
What do the contents show in /tmp/xenv? Wouldn't that give you the environment that the xserver uses (rather than any environment created for an xterm child process)?
I tried your suggestion. The contents of /tmp/xenv are the same as normal shells, they have my user-modfied path that includes /usr/local/bin. Actually, any X11 terminal that is opened by the Applications menu of X11.app has the ENV from my config file.
The xterm that opened at the beginning of the session from .xinitrc.d/99-wm.sh still has the shorter path without /usr/local/bin and is not reading my config.
because the xterm in your xinitrc is a child process of xinit which is a child of startx which can be a child of either X11.app or launchd (depending on what $DISPLAY is and how you launched the server). The xterms launched from the menu are children of X11.app itself (which gets its environment from your login shell).
This is with copies of the same bash config file in three places: ~/.profile, ~/.bash_profile, and /etc/bashrc. I'm going to keep those copies in place until I get to the bottom of it.
Perhaps what I'm seeing is normal. Is it normal for my bash config not to be loaded at the xterm that is invoked from .xinitrc.d/99-wm.sh ? If so then perhaps the wm I'm testing is not reading its ENV properly.
There's no such thing as "my bash config" ... you have multiple config files that are used differently depending on invocation.
Am 23.03.2011 um 19:44 schrieb Jeremy Huddleston:
As I mentioned earlier, it has to do with X11.app inheriting a login shell environment from ~/.bash_profile, ~/.bash_login, or ~/.profile ... which means it does not use ~/.bashrc. Non-login shells use ~/.bashrc. If you want your ~/.bashrc used in login shells as well, make sure you source it in your ~/.bash_profile
I'm not using bash, I'm true to tcsh. It works as described: What I set in ~/.login appears in the environment of the X clients. (The question stays: Why do I have to set the environment values twice?) And X11.app obviously knows the value of $HOME; why doesn't it launch its X clients in $HOME? GNU Emacs, FontForge, xterm – all are in /! X11.app has PWD=/Users/me. Why do the X clients forget it or set it to /? They have HOME=/Users/me set. -- Greetings Pete ~ o ~_\\_/\ ~ O O
On Mar 23, 2011, at 14:24, Peter Dyballa wrote:
Am 23.03.2011 um 19:44 schrieb Jeremy Huddleston:
As I mentioned earlier, it has to do with X11.app inheriting a login shell environment from ~/.bash_profile, ~/.bash_login, or ~/.profile ... which means it does not use ~/.bashrc. Non-login shells use ~/.bashrc. If you want your ~/.bashrc used in login shells as well, make sure you source it in your ~/.bash_profile
I'm not using bash, I'm true to tcsh. It works as described: What I set in ~/.login
which is analogous to ~/.bash_profile or ~/.profile for bash users
appears in the environment of the X clients. (The question stays: Why do I have to set the environment values twice?)
And the answer remains, "you don't" ;>
And X11.app obviously knows the value of $HOME; why doesn't it launch its X clients in $HOME?
Because it doesn't do anything with $HOME. There is no chdir() nor use of $HOME in the server itself.
GNU Emacs, FontForge, xterm – all are in /! X11.app has PWD=/Users/me. Why do the X clients forget it or set it to /? They have HOME=/Users/me set.
I just don't see that behavior at all...
participants (4)
-
Dave Ray
-
Jeremy Huddleston
-
Peter Dyballa
-
robert delius royar