Re: setting PATH for GUI to provide to apps?
- From: "Steven de Mena" <steve@xxxxxxxxxxxxxxx>
- Date: Tue, 15 Aug 2006 15:56:57 -0700
"*" <*@*.*> wrote in message news:1155616646_15@xxxxxxxxxxxxxx
On 2006-08-14 23:10:08 -0500, "Grant" <qzectb@xxxxxxxxx> said:
I'm an old hand at Unix, but a Mac OS newbie, and I've been unable to
find an answer to the following question:
How does one control the search path that is passed to apps by the GUI
so that they can find other executable programs?
For example, I've installed a lot of GNU-type command-line and X11
programs that have for some reason landed in /sw/bin rather than
/usr/local/bin. Now for my command shell (tcsh), I've got the path
correctly set up, so that if I use "open foo.app" from the terminal
command line, the app opens find AND it finds any executables (e.g.,
ImageMagick filters) it needs from /sw/bin. But if I open the same
app via the GUI, it remains unaware that it should search /sw/bin for
those filters, and the program either dies or disables the relevant
functions.
Thanks in advance for any pointers.
- Grant
P.S. I'm aware that many apps allow paths to required executables to
be manually specified in an application-specific preference file. I'm
looking for a more global way of solving the problem once and for all.
Hi,
Look for info about the environment.plist file inside the
user's ~/.MacOSX subdir:
<http://developer.apple.com/qa/qa2001/qa1067.html> Use this
method to set standard *ix env-vars such as $PATH, $MANPATH,
etc. To test it, put a setting for $FOOBAR in there, something
that the various shell init scripts don't set, and start up a
Terminal session to see if it's set to what you expect. ;)
ATM I think setting things like $LD_LIBRARY_PATH or
$DYLD_LIBRARY_PATH could cause OSX to find wrongly-built libs
such as libgif, libpng, etc. esp. if your filesystem is _not_
case-sensitive. The GUI subsystem wants to be able to find
libGIF, libPNG, etc. in the frameworks, not the standard
open-source versions in /usr/local/lib etc. I had a
case-sensitive HFS+ bootvol at the time, too, and I don't feel
like testing this again to see if it's been fixed (too many
missing symbols and other mismatches in Apple's u-c frameworks
of the same libs, so you get lots & lots of crashdumps as you
do Finder things ;) ).
To get the boot phases and other deep-down *ix stuff to realise
your $PATH etc., you'll need to edit various scripts such as
/etc/rc, /etc/rc.common, and chase others down (the 'at' and
'cron' scripts may change these env-vars, too, which may
involve setting 'launchd's environment its own special ways).
This is on top of the usual shell init scripts e.g.
/etc/bashrc, /etc/login, etc.
The trick to get the 'root' things to use your $PATH etc. is to
enable the 'root' user so it'll have a home subdir under
/var/root, then create an appropriate
~/.MacOSX/environment.plist for root there just as with any
user. btw a similar trick for the system to use many GUI
settings is to login as root and set-up its System Prefs panels
again as any user -- this way your system can adjust ColorSync
and many other things even before presenting the login panels
and such; you should actually see such visible adjustments go
'live' as the system is booting. :)
A lot of this is my own first-hand info, I don't know if anyone
has written all this up anywhere as a single collection. :)
In Windows you would just edit the "System Variables" PATH and it would
effect everything and everyone.
Steve
.
- Follow-Ups:
- Re: setting PATH for GUI to provide to apps?
- From: Tom Stiller
- Re: setting PATH for GUI to provide to apps?
- References:
- setting PATH for GUI to provide to apps?
- From: Grant
- setting PATH for GUI to provide to apps?
- Prev by Date: G5 Processor Upgrade
- Next by Date: Re: MacPro
- Previous by thread: Re: setting PATH for GUI to provide to apps?
- Next by thread: Re: setting PATH for GUI to provide to apps?
- Index(es):
Relevant Pages
|
