Here's another side effect of the change - which I have worked around, so I can work, and don't really understand. If I have a application menu entry Terminal => xterm -vb -lc -sb -sl 5000 The xterm starts and seems OK. However if I use: emacs -nw I find that Control-O is apparently not working. Emacs is not actually seeing it, if I type describe-key ^O into emacs nothing happens. I have ^O bound to 'Command open-line'. Emacs in this case is version 22.2.1 from macports - although I've not recompiled it against the new libraries with 2.3.0 rc4. I also get redraw problems in the terminal, as if the terminfo isn't working quite correctly - bits of the Emacs minibuffer 'go missing'- somewhat as if the terminal is not configured correctly for the command sequence it's getting. The terminal type is xterm-color. If I start an xterm from this xterm - the sub-shell xterm runs Emacs impeccably. This is weird - both the terminals started by X and the one started by hand appear to have the same environment and stty settings. Well I notice that the xterms are running with luit - well it seems that one started by X is - the one I started by hand isn't. I presumed that the one started by hand is affected by the locale code in my startup sequence - and essentially things are solved by inserting locale setting code before calling /usr/X11/bin/xterm - which is what uxterm does. So changing the menu setting to call uxterm is the solution - except that it doesn't obey my Xresources which talks about Xterms.. I've worked around things by adapting the uxterm script into a private xterm program. On 15 Jun 2008, at 06:12, Jeremy Huddleston wrote:
That's right, and it will continue to be that way. The PATH inherited by the application isn't being altered by your .profile. The .app is now (correctly) getting the same environment that any other apps get.
Google for environment.plist
--Jeremy
On Jun 14, 2008, at 12:11, Peter Collinson wrote:
There seems to be a change from previous behaviour - (nearly) all the commands in my Applications menu have stopped working.
Most are calls to shells scripts in my ~/bin... and so it looks as if the code has stopped respecting my private PATH. The command that's working calls xterm - so it's picking up the default PATH.
Sorry if this has been flagged before.
Regards _____________________________________________ Peter Collinson
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev