env variables and launchd problem
I want to ask again because nobody replied to my previous post, and maybe I should provide more info. My environment variables do not seem to be passed to X11 apps when starting up XQuartz with launchd. A different set of env variables are there. I am not sure when this problem started, I only just now discovered it. I launched an xterm from ~/.xinitrc.d/whatever.sh and typed 'env'. I could post the actual values but I don't think it's important. I can fix the problem by adding the appropriate variables to ~/.MacOSX/environment.plist. But then I have two files to maintain, /etc/bashrc and ~/.MacOSX/environment.plist. I would prefer not to have to do that, unless that is the expected way. According to the XQuartz FAQ (http://xquartz.macosforge.org/trac/wiki/X11-UsersFAQ) XQuartz should inherit my shell environment, and says I should post to this list of it isn't. I'm using the latest XQuartz 2.6.1 final on Snow Leopard 10.6.6. I have removed /Applications/Utilities/X11.app (actually, compressed it) and renamed /usr/X11 and /usr/X11R6 to /usr/X11-temp and /usr/X11R6-temp. This is to be absolutely sure there aren't conflicts in the two X11 environments. (Is this bad?) The problem happens regardless of what I launch from my ~/.xinitrc.d/whatever.sh. The problem does not occur if I start XQuartz without launchd, for example, by typing 'startx' at the terminal. I looked over my system and don't think it''s a config issue, but if someone confirms the problem is limited only to my machine, I will look further. Could someone chime in and let me know if this is normal or not, my env in /etc/bashrc not being passed to the apps launched from ~/.xinitrc.d/whatever *IF and only IF* they are launched by launchd. Thanks.
I think the problem is that you are setting the values in .bashrc. X11 inherits your *login* shell environment. This is set by .profile (not .bashrc). The way I work around this is to add the following to my .profile which causes my .bashrc to be included as well: if [ "${BASH-no}" != "no" ]; then [ -r ${HOME}/.bashrc ] && . ${HOME}/.bashrc fi On Mar 21, 2011, at 16:45, Dave Ray wrote:
I want to ask again because nobody replied to my previous post, and maybe I should provide more info.
My environment variables do not seem to be passed to X11 apps when starting up XQuartz with launchd. A different set of env variables are there. I am not sure when this problem started, I only just now discovered it. I launched an xterm from ~/.xinitrc.d/whatever.sh and typed 'env'. I could post the actual values but I don't think it's important.
I can fix the problem by adding the appropriate variables to ~/.MacOSX/environment.plist. But then I have two files to maintain, /etc/bashrc and ~/.MacOSX/environment.plist. I would prefer not to have to do that, unless that is the expected way.
According to the XQuartz FAQ (http://xquartz.macosforge.org/trac/wiki/X11-UsersFAQ) XQuartz should inherit my shell environment, and says I should post to this list of it isn't.
I'm using the latest XQuartz 2.6.1 final on Snow Leopard 10.6.6. I have removed /Applications/Utilities/X11.app (actually, compressed it) and renamed /usr/X11 and /usr/X11R6 to /usr/X11-temp and /usr/X11R6-temp. This is to be absolutely sure there aren't conflicts in the two X11 environments. (Is this bad?)
The problem happens regardless of what I launch from my ~/.xinitrc.d/whatever.sh.
The problem does not occur if I start XQuartz without launchd, for example, by typing 'startx' at the terminal.
I looked over my system and don't think it''s a config issue, but if someone confirms the problem is limited only to my machine, I will look further.
Could someone chime in and let me know if this is normal or not, my env in /etc/bashrc not being passed to the apps launched from ~/.xinitrc.d/whatever *IF and only IF* they are launched by launchd.
Thanks.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Mar 21, 2011, at 5:11 PM, Jeremy Huddleston wrote:
I think the problem is that you are setting the values in .bashrc. X11 inherits your *login* shell environment. This is set by .profile (not .bashrc).
Actually, for bash, the login shell reads .bash_profile (and only that file - you need to explicitly load your .bashrc from within that file if you want it). - Jordan
On Mar 21, 2011, at 17:29, Jordan K. Hubbard wrote:
On Mar 21, 2011, at 5:11 PM, Jeremy Huddleston wrote:
I think the problem is that you are setting the values in .bashrc. X11 inherits your *login* shell environment. This is set by .profile (not .bashrc).
Actually, for bash, the login shell reads .bash_profile (and only that file - you need to explicitly load your .bashrc from within that file if you want it).
Well it reads .profile if .bash_profile and .bash_login are absent ... unless in posix mode. For anyone caring, there is a book written on this topic in the INVOCATION section of bash(1), but here's a snippet: When bash is invoked as an interactive login shell, or as a non-inter- active shell with the --login option, it first reads and executes com- mands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.
Am 22.03.2011 um 00:45 schrieb Dave Ray:
I can fix the problem by adding the appropriate variables to ~/.MacOSX/environment.plist. But then I have two files to maintain, / etc/bashrc and ~/.MacOSX/environment.plist. I would prefer not to have to do that, unless that is the expected way.
One possible solution to this is make bashrc the "client" of ~/.MacOSX/ environment.plist. You can use constructs like for example this: export PATH=$(defaults read "${HOME}/.MacOSX/environment" PATH) For whatever variable you need. When $HOME is set, then the environment of the logging in user will be set. 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! The defaults command can be used anywhere else. -- Greetings Pete There are three types of people in this world: those who can count, and those who cannot.
On Mar 22, 2011, at 15:54, Peter Dyballa wrote:
Am 22.03.2011 um 00:45 schrieb Dave Ray:
I can fix the problem by adding the appropriate variables to ~/.MacOSX/environment.plist. But then I have two files to maintain, /etc/bashrc and ~/.MacOSX/environment.plist. I would prefer not to have to do that, unless that is the expected way.
One possible solution to this is make bashrc the "client" of ~/.MacOSX/environment.plist. You can use constructs like for example this:
export PATH=$(defaults read "${HOME}/.MacOSX/environment" PATH)
For whatever variable you need. When $HOME is set, then the environment of the logging in user will be set.
Why do you find yourself needing ~/.MacOSX/environment at all?
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.
The defaults command can be used anywhere else.
NSDefaults have nothing to do with environment variables.
Am 23.03.2011 um 00:48 schrieb Jeremy Huddleston:
Why do you find yourself needing ~/.MacOSX/environment at all?
It's so simple (elegant?) and it can be made the single point of failure. Instead of constantly updating a dozen different files it's better to update these files once to use the contents of ~/.MacOSX/ environment.plist and then to maintain this file only. The file is needed to set the environment in which the Mac OS X processes run. They are not launched via some shell that is configured by its init files. It nevertheless allows to override these settings in the init or RC files for use in shells. And this works instantaneously, no log out and log in are needed to to make them work. So one can easily develop improvements of the settings in ~/.MacOSX/environment.plist
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.
The defaults command can be used anywhere else.
NSDefaults have nothing to do with environment variables.
It can be used used this way: setenv LANG `defaults read "$ {HOME}/.MacOSX/environment" LANG`. -- Greetings Pete A blizzard is when it snows sideways.
participants (4)
-
Dave Ray
-
Jeremy Huddleston
-
Jordan K. Hubbard
-
Peter Dyballa