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
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
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
Just in case it helps: I believe I saw something similar a while ago using pwm in an Xnest window, too. If I ran pwm (window manager) from my .xinitrc, hotkeys (meta-E for an xterm, for example) didn't work, but if I waited and ran pwm from the xterm that was automatically started, hotkeys worked as expected. I thought it was just Xnest being weird, then forgot to follow up on this list (sorry!). - Brian On Mon, Jun 16, 2008 at 5:31 PM, Peter Collinson pc-at-hillside.co.uk |Xquartz-dev/personal| <...> wrote:
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
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
-- Henny Youngman - "When I told my doctor I couldn't afford an operation, he offered to touch-up my X-rays."
participants (3)
-
Brian Bender
-
Jeremy Huddleston
-
Peter Collinson