Fwd: (OT) path_helper [was Re: Xterm not reading dotfiles]
Fwd: (OT) path_helper [was Re: Xterm not reading dotfiles]
- Subject: Fwd: (OT) path_helper [was Re: Xterm not reading dotfiles]
- From: "Nathaniel Gray" <email@hidden>
- Date: Sun, 18 Nov 2007 15:10:55 -0800
Oops, should have hit reply-all...
---------- Forwarded message ----------
From: Nathaniel Gray <email@hidden>
Date: Nov 18, 2007 3:10 PM
Subject: Re: (OT) path_helper [was Re: Xterm not reading dotfiles]
To: "Andrew J. Hesford" <email@hidden>
On Nov 18, 2007 2:47 PM, Andrew J. Hesford <email@hidden> wrote:
> On Nov 18, 2007, at 4:15 PM, Nathaniel Gray wrote:
>
> > Funny that path_helper came up on this list. I noticed that zsh
> > shells opened in mrxvt under X took a fraction of a second to start
> > but those opened in Terminal.app took about 5 seconds. After much
> > digging, I found that the cause was path_helper. (mrxvt was opening
> > zsh as a non-login shell and thus not triggering path_helper.) The
> > regex it's using in line 18 is really really really slow. I replaced
> > it with this one and it runs in a snap:
> > [[ "$NEWPATH" = "@(${p}|${p}:*|*:${p}|*:${p}:*)" ]] && continue
>
> Well, I put this into my path_helper, and it doesn't work as expected.
> I know that path_helper first initializes a default path: /usr/bin:/
> bin:/usr/sbin:/sbin. To see if your new line was working, I first set
> a default path out of order: /bin:/usr/bin:/usr/sbin:/sbin. Then, I
> started zsh and let it run path_helper. If path_helper was working
> correctly, you'd see these four elements in my order, and then the
> extra elements at the end. An incorrect run would overwrite my order
> with the default order.
>
> Instead, the path started with /bin:/usr/bin:/usr/sbin:/sbin:/usr/bin:/
> bin:/usr/sbin:/sbin. The redundancy and ordering tells me that
> path_helper doens't match anything in my path, so it just appends its
> entire contents to mine. The original line in path_helper behaves
> correctly.
Whoops, I added "safety quotes" around the glob after testing, but it
looks like that breaks things. This should work:
[[ "$NEWPATH" = @(${p}|${p}:*|*:${p}|*:${p}:*) ]] && continue
>
> The OR'ed globs make sense; but what is the "@" supposed to do? I
> don't know enough about bash...
The @ makes it do a disjunction over the patterns.
> > I was also surprised to find path_helper setting the MANPATH, since
> > it's both unnecessary and counterproductive to do so. These days man
> > uses the configuration setup in /etc/man.conf to automatically work
> > out the proper man page for a given executable *unless* MANPATH is
> > set. So if MANPATH is set I have to remember to configure it in
> > addition to PATH instead of letting man just be smart about it.
>
> The thing I dislike about /etc/man.conf is that it isn't consistent.
> Every system I've used respects MANPATH when set. However, FreeBSD
> doesn't have man.conf, and the FreeBSD man(1) man page (ha!) doesn't
> mention it. Plus, having path_helper manage both sets gives me a
> single place to govern these things. This seems to be inspired by the
> Gentoo env-update system, which is a much more general mechanism for
> setting environment options.
Ok, but this isn't FreeBSD or Gentoo, this is Mac OS X. (Is
path_helper standard on other systems?) We like things simpler 'round
here. As it is you have *two* config sets to worry about
(/etc/paths{,.d/*} and /etc/manpaths{,.d/*}) when you only need one.
Plus, if you use man.conf and add something to your path on-the-fly
then manpath Just Works, which seems very Mac.
Cheers,
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden