I am starting this new thread because of a few more problems I see. In ~/.xinitrc.d/50-clients.sh I had just 'gkrellm &' which worked before. Now I have to add the path to the X client, /sw/bin/. PWD in GNU Emacs is /, but HOME is OK. When I launch uxterm the Programmes menu it has PWD=$HOME, when I launch it from ~/.xinitrc.d/50- clients.sh it has PWD=/. The value of PATH in ~/.xinitrc.d/50-clients.sh is PATH=/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin although 'defaults read ~/.MacOSX/environment PATH' gives /Users/pete/bin:/sw/lib/flex/bin:/sw/lib/freetype219/bin:/sw/lib/xft2/ bin:/usr/local/bin:/usr/local/texlive/2009/bin/universal-darwin:/usr/ bin:/bin:/sbin:/usr/sbin:/usr/local/sbin:/sw/sbin:/usr/X11/bin:/sw/ bin:/Developer/Tools The command "bash -c 'echo $PATH'", hopefully reporting the PATH bash uses and not what the shell sees which is interpreting this command, gives: /opt/local/bin:/opt/local/sbin:/usr/local/texlive/2010/bin/universal- darwin:/Users/pete/bin:/sw/lib/flex/bin:/sw/lib/freetype219/bin:/sw/ lib/xft2/bin:/usr/local/bin:/usr/local/texlive/2009/bin/universal- darwin:/usr/bin:/bin:/sbin:/usr/sbin:/usr/local/sbin:/sw/sbin:/usr/X11/ bin:/sw/bin:/Developer/Tools which indeed is close to the environment in which GNU Emacs is running, because it's being launched as env PATH=/usr/local/texlive/2010/bin/universal-darwin:/Users/pete/ bin:/sw/lib/flex/bin:/sw/lib/freetype219/bin:/sw/lib/xft2/bin:/usr/ local/bin:/usr/local/texlive/2009/bin/universal-darwin:/usr/bin:/bin:/ sbin:/usr/sbin:/usr/local/sbin:/sw/sbin:/usr/X11/bin:/sw/bin:/ Developer/Tools MANPATH=/usr/local/texlive/2010/texmf/doc/man:/usr/ local/share/man:/usr/local/clamXav/share/man:/usr/share/man:/usr/X11/ share/man:/sw/share/man:/usr/local/texlive/2009/texmf/doc/man:/opt/ local/share/man:/Developer/usr/llvm-gcc-4.2/share/man:/sw/lib/ perl5/5.8.8/man INFOPATH=/usr/local/texlive/2010/texmf/doc/info:/usr/ local/texlive/2009/texmf/doc/info:/usr/share/info:/usr/local/share/ info:/sw/share/info:/opt/local/share/info:/Applications/EmacsJCVS.app/ Contents/Resources/info:/Applications/EmacsJCVS.app/Contents/Resources/ extra/info emacs-24.0.50 -geometry 100x55+696+145 -T 'TeX Live 2010@24.0.50 ' -xrm 'Emacs*iconName: TeX Live-2010' --debug-init & The environment set up here is inherited by processes spawned by GNU Emacs, for example a pdflatex run. But not by tcsh running in *shell* buffer or running in uxterm. The *shell* buffer in NS Emacs 24.0.50 /has/ inherited the environment and PATH setting. The value of SHELL in ~/.xinitrc.d/50-clients.sh is /bin/tcsh, the value of X11_PREFS_DOMAIN is org.macports.X11, the script starts with echo "50-clients.sh" -- Greetings Pete "Klingons do not believe in indentation - except perhaps in the skulls of their project managers."
I ran env in uxterm's in X11.app and in MacPorts' XQuartz. Clearly the latter does not read ~/.MacOSX/environment.plist or does not pass the so built environment to children processes. The uxterm has none of the environment settings set. It even has: LC_CTYPE=en_US.UTF-8 XTERM_LOCALE=en_US.UTF-8 which does not reflect what I have set in System Preferences. It also sets PWD and cwd to /, while in X11.app it's value is my home directory. With MacPorts I have SHLVL=3, in X11.app I have SHLVL=5. The uxterm in MacPorts has X11_PREFS_DOMAIN=org.macports.X11, in X11.app it's X11_PREFS_DOMAIN=org.x.X11 – a few things do work. -- Greetings Pete Be careful of reading health books, you might die of a misprint. – Mark Twain
On Jan 31, 2011, at 10:50, Peter Dyballa wrote:
I ran env in uxterm's in X11.app and in MacPorts' XQuartz. Clearly the latter does not read ~/.MacOSX/environment.plist or does not pass the so built environment to children processes. The uxterm has none of the environment settings set. It even has:
It has nothing to do with XQuartz.app or X11.app reading or not reading environment.plist. It has to do with your launchd (on Leopard) not reading environment.plist.
Am 31.01.2011 um 20:20 schrieb Jeremy Huddleston:
I ran env in uxterm's in X11.app and in MacPorts' XQuartz. Clearly the latter does not read ~/.MacOSX/environment.plist or does not pass the so built environment to children processes. The uxterm has none of the environment settings set. It even has:
It has nothing to do with XQuartz.app or X11.app reading or not reading environment.plist. It has to do with your launchd (on Leopard) not reading environment.plist.
Why did it work before, one week ago, to supply all X clients with a proper environment? Why is the situation of Mac OS X 10.4, Tiger, back? How can I make launchd supply a reasonable environment to its "clients"? Or do I need to augment each of the ~/.xinitrc.d/* scripts with environment settings? How would XQuartz know to lookup X clients in /opt/local/bin when the MacPorts installer put the statement to augment PATH in my unused ~/.cshrc? -- Greetings Pete Time is an illusion. Lunchtime, doubly so.
On Jan 31, 2011, at 13:08, Peter Dyballa wrote:
Am 31.01.2011 um 20:20 schrieb Jeremy Huddleston:
I ran env in uxterm's in X11.app and in MacPorts' XQuartz. Clearly the latter does not read ~/.MacOSX/environment.plist or does not pass the so built environment to children processes. The uxterm has none of the environment settings set. It even has:
It has nothing to do with XQuartz.app or X11.app reading or not reading environment.plist. It has to do with your launchd (on Leopard) not reading environment.plist.
Why did it work before, one week ago, to supply all X clients with a proper environment?
Probably because a week ago you weren't launching X11.app from launchd. You probably launched it yourself.
Why is the situation of Mac OS X 10.4, Tiger, back?
This is a really general question. What about Tiger is back?
How can I make launchd supply a reasonable environment to its "clients"?
You can't get it to use environment.plist. You probably want to set stuff up in ~/.profile
Or do I need to augment each of the ~/.xinitrc.d/* scripts with environment settings?
That would work too.
How would XQuartz know to lookup X clients in /opt/local/bin when the MacPorts installer put the statement to augment PATH in my unused ~/.cshrc?
You probably want to put it in ~/.login (rather than ~/.profile) since you're using csh.
Am 01.02.2011 um 01:07 schrieb Jeremy Huddleston:
Why did it work before, one week ago, to supply all X clients with a proper environment?
Probably because a week ago you weren't launching X11.app from launchd. You probably launched it yourself.
I am clicking on the X11 icon in Dock. Is this by myself and without launchd? Should I launch /Applications/MacPorts/X11.app with open from some command line? Why was this not necessary last week?
Why is the situation of Mac OS X 10.4, Tiger, back?
This is a really general question. What about Tiger is back?
In Tiger, X11 either did not inherit or did not pass (or did both) the environment set by ~/.MacOSX/environment.plist.
How can I make launchd supply a reasonable environment to its "clients"?
You can't get it to use environment.plist. You probably want to set stuff up in ~/.profile
There I have: PATH=`defaults read "${HOME}/.MacOSX/environment" PATH` MANPATH=`defaults read "${HOME}/.MacOSX/environment" MANPATH` INFOPATH=`defaults read "${HOME}/.MacOSX/environment" INFOPATH` export INFOPATH MANPATH PATH I don't see for example INFOPATH not at all...
Or do I need to augment each of the ~/.xinitrc.d/* scripts with environment settings?
That would work too.
How would XQuartz know to lookup X clients in /opt/local/bin when the MacPorts installer put the statement to augment PATH in my unused ~/.cshrc?
You probably want to put it in ~/.login (rather than ~/.profile) since you're using csh.
Ah, that would explain the missing INFOPATH! (Well, missing since last week. Before, last year for example, I was not missing this.) -- Greetings Pete This is a signature virus. Add me to your signature and help me to live!
On Feb 1, 2011, at 02:48, Peter Dyballa wrote:
Am 01.02.2011 um 01:07 schrieb Jeremy Huddleston:
Why did it work before, one week ago, to supply all X clients with a proper environment?
Probably because a week ago you weren't launching X11.app from launchd. You probably launched it yourself.
I am clicking on the X11 icon in Dock. Is this by myself and without launchd?
Clicking on the X11 icon in Dock *will* get you your environment.plist settings. Launcing 'xterm' from Terminal.app *won't*.
Why is the situation of Mac OS X 10.4, Tiger, back?
This is a really general question. What about Tiger is back?
In Tiger, X11 either did not inherit or did not pass (or did both) the environment set by ~/.MacOSX/environment.plist.
Huh... odd.
How can I make launchd supply a reasonable environment to its "clients"?
You can't get it to use environment.plist. You probably want to set stuff up in ~/.profile
There I have:
PATH=`defaults read "${HOME}/.MacOSX/environment" PATH` MANPATH=`defaults read "${HOME}/.MacOSX/environment" MANPATH` INFOPATH=`defaults read "${HOME}/.MacOSX/environment" INFOPATH` export INFOPATH MANPATH PATH
I don't see for example INFOPATH not at all...
Or do I need to augment each of the ~/.xinitrc.d/* scripts with environment settings?
That would work too.
How would XQuartz know to lookup X clients in /opt/local/bin when the MacPorts installer put the statement to augment PATH in my unused ~/.cshrc?
You probably want to put it in ~/.login (rather than ~/.profile) since you're using csh.
Ah, that would explain the missing INFOPATH! (Well, missing since last week. Before, last year for example, I was not missing this.)
That may have been before we fixed X11 to use the login environment. --Jeremy
Am 01.02.2011 um 18:30 schrieb Jeremy Huddleston:
I am clicking on the X11 icon in Dock. Is this by myself and without launchd?
Clicking on the X11 icon in Dock *will* get you your environment.plist settings.
Launcing 'xterm' from Terminal.app *won't*.
I always do click on the X11 icon in Dock. Launching xterm from Terminal or such in my opinion is insane behaviour (as long as no X server is running). I'm healthy conservative. Launching /Applications/MacPorts/X11.app/ as open /Applications/MacPorts/X11.app/ in NS Emacs 24.0.50, the Cocoa variant of the X client, gives in Console: 01.02.11 19:05:36 org.macports.startx[54646] Notice PWD=/ This obviously is not correct.
Why is the situation of Mac OS X 10.4, Tiger, back?
This is a really general question. What about Tiger is back?
In Tiger, X11 either did not inherit or did not pass (or did both) the environment set by ~/.MacOSX/environment.plist.
Huh... odd.
I wasn't alone with this. A few, to say the least, TeX users had the same problem (needing for example Ghostscript or xpdf or xdvi, the viewer for the old native TeX output, exhibiting some nice features and being lightning fast), that I built a Platypus application to install some files and change some more (to create a shell alias command for example), that X11.app inherits some useful environment variables and passes them to the clients.
How would XQuartz know to lookup X clients in /opt/local/bin when the MacPorts installer put the statement to augment PATH in my unused ~/.cshrc?
You probably want to put it in ~/.login (rather than ~/.profile) since you're using csh.
Ah, that would explain the missing INFOPATH! (Well, missing since last week. Before, last year for example, I was not missing this.)
That may have been before we fixed X11 to use the login environment.
IMO this change did not fix things but introduce at least one bug: now I don't have my login environment. I have it the X clients launched from the same ~/.xinitrc.d/* scripts from /Applications/Utilities/ X11.app, I have it in Terminal or the AppKit, NS, or Carbon Emacsen, native Aqua or Quartz or whatever clients or applications. I do not have my login environment in the X clients launched from the same ~/.xinitrc.d/* scripts from /Applications/MacPorts/X11.app – since ten days or so. I even have no home directory. I get logged in in /. In Terminal or the AppKit, NS, or Carbon Emacsen it's ~. Putting some 'setenv XYZ `defaults read ~/.MacOSX/environment XYZ`' into ~ /.login augments the shell environment. The defaults and tcsh programmes seem to work well, no fixes needed. -- Greetings Pete There's no place like ~ – (UNIX Guru)
Am 01.02.2011 um 18:30 schrieb Jeremy Huddleston:
That may have been before we fixed X11 to use the login environment.
In case this MacPorts version of X11 inherits my login environment it does not pass it to its clients, For example uxterm does not inherit INFOPATH although it's set in ~/.login. Xterm has it – but it uses a login shell. In GNU Emacs 23.2, the stable version, I have: (getenv "INFOPATH") nil (getenv "MANPATH") nil (getenv "PATH") "/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin" It's nothing that *I* set. In an X session environment launched with 'open /Applications/MacPorts/ X11.app' from a shell that has everything (set). -- Greetings Pete War springs from unseen and generally insignificant causes. – Anonymous
I started to deactivate xorg-server 1.9.3 and activate xorg-server- devel 1.9.3, and back. Now I get with both: Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: Xquartz starting: Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: X.Org X Server 1.9.3 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: Build Date: 20101229 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: Thread Assertion Failed: self=Unknown Thread, expected=Xserver Thread Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: xprFrame.c:xprInit:480 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 0 X11.bin 0x00016b44 spewCallStack + 36 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 1 X11.bin 0x0001ade8 xprInit + 72 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 2 X11.bin 0x0001c79c xprHideWindows + 3404 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 3 X11.bin 0x00013214 QuartzSetupScreen + 52 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 4 X11.bin 0x0000f0e8 DarwinPrintBanner + 632 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 5 X11.bin 0x000e5454 AddScreen + 388 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 6 X11.bin 0x0000fae4 InitOutput + 180 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 7 X11.bin 0x000d5d18 dix_main + 632 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 8 X11.bin 0x000155e8 QuartsResyncKeymap + 2232 Feb 2 00:26:22 localhost [0x0-0xd80d8].org.macports.X11[29009]: 9 libSystem.B.dylib 0x912700d4 _pthread_start + 320 -- Greetings Pete Upgraded, adj.: Didn't work the first time.
Am 01.02.2011 um 18:30 schrieb Jeremy Huddleston:
That may have been before we fixed X11 to use the login environment.
Before I had to reboot I "fixed" as well one thing, the missing of the org.macports.startx.plist file you mentioned, in order to have all X clients, even those launched from Terminal or the non-X11 Emacsen, contact the MacPorts X server. Using the not installed file from the X server build area and /System/Library/LaunchAgents/org.x.startx.plist I built a variant with just a few differences: /System/Library/LaunchAgents/org.x.startx.plist vs. /Library/ LaunchAgents/org.macports.startx.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd "> <plist version="1.0"> <dict> <key>Label</key> <string>org.x.startx</string> <string>org.macports.startx</ string> <key>ProgramArguments</key> <array> <string>/usr/X11/bin/startx</string> <string>/opt/local/bin/ startx</string> </array> <key>ServiceIPC</key> <true/> <key>Sockets</key> <dict> <key>org.x:0</key> <key>org.macports:0</key> <dict> <key>SecureSocketWithKey</key> <string>DISPLAY</string> </dict> </dict> </dict> </plist> Could this file cause the problems with my login environment? At least xdpyinfo or xwininfo don't launch a second X server as before. -- Greetings Pete Chicago, n.: Where the dead still vote … early and often!
On Feb 2, 2011, at 07:28, Peter Dyballa wrote:
Am 01.02.2011 um 18:30 schrieb Jeremy Huddleston:
That may have been before we fixed X11 to use the login environment.
Before I had to reboot I "fixed" as well one thing, the missing of the org.macports.startx.plist file you mentioned, in order to have all X clients, even those launched from Terminal or the non-X11 Emacsen, contact the MacPorts X server. Using the not installed file from the X server build area and /System/Library/LaunchAgents/org.x.startx.plist I built a variant with just a few differences:
/System/Library/LaunchAgents/org.x.startx.plist vs. /Library/LaunchAgents/org.macports.startx.plist
Could this file cause the problems with my login environment? At least xdpyinfo or xwininfo don't launch a second X server as before.
It looks alright to me.
I cleaned my disk a bit, removed many old MacPorts builds of xorg- server and xorg-server-devel and finally rebuilt xorg-server @1.9.3_0+docs. The shells xterm, uxterm, GNU Emacsen start now in ~, environment is inherited, SHLVL=5 – just blackbox WM now crashes again. No logout, no reboot. yet. -- Greetings Pete No matter which way you ride, it's uphill and against the wind. – First Law of Bicycling
Am 06.02.2011 um 19:15 schrieb Peter Dyballa:
The shells in xterm, uxterm, GNU Emacsen start now in ~, environment is inherited, SHLVL=5 – just blackbox WM now crashes again.
After building, installing, and activating xorg-server-devel @1.9.3.902_0+docs I gain land in /, SHLVL=2, PATH is shortened to / opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin, and BackboxWM launches. Logout and reboot (into Tiger, to test something) did not change anything. -- Greetings Pete Encryption, n.: A powerful algorithmic encoding technique employed in the creation of computer manuals.
participants (3)
-
Jeremy Huddleston
-
Peter Dyballa
-
Peter Dyballa