[email protected] wrote:
[]
>> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister
>>
>> -u /Applications/Utilities/X11.app
>>
>> When you restart X11 after this, the PATH should be correctly set in your
>> xterm, even without running xterm -ls.
>>
>> If it works, I'll try to explain.
>> Martin
> No, this does not help. The behaviour remains the same. I do get the
> following message though when executing lsregister:
> "ThrottleProcessIO: throttling disk i/o"
> I also entered the command with sudo, but that makes not difference at
> all.
That's a pity. For me it did help. I had what I thought a similar PATH
problem as you on this laptop account here; not on other accounts and on
other machines. But re-reading your message, I believe now that your
problem is not caused by a bug, see below.
> As far as I can tell, this command would unregister X11.app from the
> LaunchServices database, but I don't know what the consequences of
> that action would be.
OK, here is the explanation anyway:
This command does indeed unregister X11.app, but it is automatically
re-registered immediately. The effect is that if it was registered
incorrectly before, it is now registered correctly. What was incorrect?
If you look at the registered information with
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister
-dump | grep "/X11.app" -A14 |grep exec
it should show
executable: Contents/MacOS/X11
In my case, it showed (no idea why)
executable: Contents/MacOS/X11.bin
MacOS/X11 is a wrapper script that executes a login shell, and thus sets
the right environment, before running the actual executable "X11.bin".
In my case, the wrapper script was never executed and therefore PATH
rested at its minimal version
/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin
In your case, it seems to me now that the behavior of PATH is as can be
expected. Have a look at the wrapper script
/Applications/Utilities/X11.app/Contents/MacOSX/X11. For bash-users, it
executes
exec -l "${SHELL}" --login -c 'exec "$...@}"' - "$...@}"
where ${SHELL} translates to /bin/bash and "$...@}" translates to
"/Applications/Utilities/X11.app/Contents/MacOSX/X11.bin -psn_0_200753"
or something similar.
I put markers into the startup scripts, and they show me that in the
default xterm started by X11, the scripts are run in the following order:
~/.MacOSX/MacOSX_environment.plist:/A/U/X11:/etc/profile:/etc/bashrc:~/.bash_profile:~/.bashrc
If you run "xterm -ls" from the X11 "Applications" menu (I assume that
this is what you mean when you say you "invoke xterm with the -ls
option"), the last ~/.bashrc is replaced by
/etc/profile:/etc/bashrc:~/.bash_profile
No ~/.bashrc is executed in this case (don't ask me why, it's what I
observe).
The weird PATH you get in your situation (4) is the result of
/etc/profile executing `/usr/libexec/path_helper -s`. On 10.5, the
path_helper script was a (very complicated) shell script, on 10.6 it is
a compiled executable, so I don't quite know what it does, but it seems
it now prepends the contents of /etc/paths and of the files in
/etc/paths.d to $PATH. On 10.5 it placed these things at the end of $PATH.
Normally, the subsequent ~/.bash_profile script would clean up the mess
by running Fink's init.sh. I don't know why it doesn't do this in your case.
I hope with these explanations you can find out what really happens in
your case. If it's your Mac, you can modify the system-wide scripts in
/etc/ to give you what you want.
--
Martn
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fink-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-users
