Re: (OT) path_helper [was Re: Xterm not reading dotfiles]
Re: (OT) path_helper [was Re: Xterm not reading dotfiles]
- Subject: Re: (OT) path_helper [was Re: Xterm not reading dotfiles]
- From: "Andrew J. Hesford" <email@hidden>
- Date: Sun, 18 Nov 2007 11:27:06 -0600
On Nov 18, 2007, at 11:08 AM, Merton Campbell Crockett wrote:
My bad! After responding to your post, I looked at the environment
for Terminal.app and noticed it had duplicate entries in the PATH
environment variable. This led to looking at the path_helper man
page and /etc/profile.
It appears that I had modified /etc/profile under Mac OS X 10.4.
When upgrading to Mac OS X 10.5, the modified /etc/profile was
preserved and the new Mac OS X 10.5 version was installed as /etc/
profile.system_default.
As a result, I never saw the "freeze" that you and several others
have reported. It makes one wonder how many of the X "problems" are
related to how, sans adequate documentation, users addressed
problems in earlier versions of Mac OS X.
As an aside, were /usr/libexec/path_helper to function as described
in the man pages, I would have little need for ~/.bash_profile or
~/.profile other than to add the paths required to use MacPorts.
So here's what I've discovered. I use the zsh shell, and never had any
problems with path_helper. Also, I moved the call to path_helper to /
etc/zshenv instead of /etc/zprofile, which forces all shells (not just
login shells) to pick up the path. This is so that I can use utilities
like unison to synchronize directories, using an SSH tunnel, even when
these utilities are not in the default system path (/usr/bin:/bin:/usr/
sbin:/sbin).
When I start bash with bash -l, to make a login shell, everything
works fine. However, when I use LaTeXiT, it calls bash -l to invoke
its commands. This causes path_helper to hang. I wrote a quick Perl
replacement for path_helper (which is a Bourne script), and pointed /
etc/profile to my replacement instead of the system script. LaTeXiT
works just fine. Curious. Aren't I doing the same thing?
Oops, no, I'm not doing the same thing, because the system path_helper
tries to preserve an existing path. My Perl script ignores any
existing path. Because path_helper preserves the existing path, it
also takes steps to avoid duplication of path elements, which I don't
do. Hence, for each path element is reads, it checks to see if it is
already in the path before adding it.
So in /etc/profile, I first clobber PATH before using path_helper to
set it, by forcing it to some initial default (along the lines of the
default system path). LaTeXiT works fine, path_helper doesn't hang.
Curious. What could be causing the hang? Divine inspiration hit me,
and it occured to me that I made a "Home" file in /etc/paths.d, with
the contents "$HOME/bin". The intention in making this file was to
automatically populate the path with the bin/ subirectory of the
user's home directory, and it was working well. However, I removed
this file from /etc/paths.d, and presto... LaTeXiT was no longer
hanging.
That's all I know. There's something about the "$HOME/bin" contents of
the file I created that wreak havoc, but only when run from LaTeXiT.
As a workaround, I moved the $HOME/bin addition to my ~/.zshenv, with
the retroactive justification that it is probably better practice to
force users to become knowledgeable before automatically adding a user-
controlled directory to their paths.
On a side note, in my fooling with bash, I noticed that my home
directory appeared in the path where I had inserted it with
path_helper, and then sometimes it seemed to appear again at the end
of the path. I don't know why, but bash might have been tinkering with
the path directly.
I hate bash! I wonder if using the true Bourne shell to run
path_helper would avoid these issues... Alas, sh is bash in Mac OS X.
--
Andrew J. Hesford <email@hidden>
Department of Electrical and Computer Engineering
University of Illinois at Urbana-Champaign
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden