From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2273 invoked by alias); 16 Mar 2015 08:08:35 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34716 Received: (qmail 2144 invoked from network); 16 Mar 2015 08:08:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2 Date: Mon, 16 Mar 2015 09:08:19 +0100 From: Roman Neuhauser To: Bart Schaefer Cc: zsh-workers@zsh.org Subject: Re: fndir introspection, site-packages documentation Message-ID: <20150316080819.GR4524@isis.sigpipe.cz> References: <20150313224121.GO4524@isis.sigpipe.cz> <150313203904.ZM25016@torch.brasslantern.com> <20150315021436.GQ4524@isis.sigpipe.cz> <150315121447.ZM27996@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150315121447.ZM27996@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) # schaefer@brasslantern.com / 2015-03-15 12:14:47 -0700: > This really doesn't belong on zsh-users any more, in fact it probaby should > have started out on zsh-workers to begin with. I haven't changed the list > target yet for this reply, but I suggest follow-ups go there. but then i'm bound to miss replies. i don't want to subscribe to zsh-workers (yet)... > Aside: I don't suppose there's any point in again begging people to stop > attaching patches as "text/x-patch" or "text/x-diff" or other silly MIME > types that half my email clients [...] i recon it'd be easier to reconfigure both halves of your email clients. :) but, sorry to make your life difficult, it wasn't deliberate. > On Mar 15, 3:14am, Roman Neuhauser wrote: > } ./Src/zsh -fc 'print -l "$ZSH_SITEFNDIR"' > } /omg/share/zsh/site-functions > > I don't have any strong objection to this although it seems like putting > this value into every shell is overkill for the specialized purpose to > which you propose to use it. Can anyone give me a situation in which an > oridinary user (i.e., not a software packager) would need this? how about: a site admin wants to install a function for all users. > Your doc change mentions > > +tt(/usr/local/share/zsh/site-functions) is always included, > +even if it does not exist, and cannot be configured away. > > That's not quite correct: --disable-site-fndir turns it off, leaving > only $prefix/share/zsh/$ZSH_VERSION/functions (or subdirs). i described what i saw in testing. what i haven't noticed is that --prefix=/usr/local is a special case. in fact, removing the hardcoded failsafe neuters the purpose of the whole thing; you may treat this as a bug report. try it yourself: % ./configure --prefix=/omg --disable-site-fndir && make && ./Src/zsh -fc 'print -l $fpath' /usr/local/share/zsh/site-functions /omg/share/zsh/5.0.7-dev-1/functions % ./configure --disable-site-fndir && make && ./Src/zsh -fc 'print -l $fpath' /usr/local/share/zsh/5.0.7-dev-1/functions the behavior with non-default --prefix is described in NEWS: - The default $fpath/$FPATH is now designed always to include /usr/local/share/zsh/site-functions. This directory does not need to exist. Sites that set an explicit site directory can put that in /etc/zshenv as before. The intention of the new path element is to increase the likelihood that locally added functions can be found with the shell running "out of the box", no matter how the shell was configured. the behavior with *default* --prefix is, well, completely contrary to the intent described: "no matter how the shell was configured" is blatantly false thanks to this special case. > Maybe the right thing is to throw all of this into a module (and doc > for that module) that can be loaded by package maintainers to provide > access to zsh's configure settings, but which other users can ignore. > The more I think about it the more I like that idea. zmodload or pkg-config? -- roman