From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2713 invoked by alias); 16 Mar 2015 17:06:12 -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: 34723 Received: (qmail 24739 invoked from network); 16 Mar 2015 17:05:57 -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 18:05:52 +0100 From: Roman Neuhauser To: zsh-workers@zsh.org Subject: Re: fndir introspection, site-packages documentation Message-ID: <20150316170552.GU4524@isis.sigpipe.cz> References: <20150313224121.GO4524@isis.sigpipe.cz> <150313203904.ZM25016@torch.brasslantern.com> <20150315021436.GQ4524@isis.sigpipe.cz> <150315121447.ZM27996@torch.brasslantern.com> <20150316080819.GR4524@isis.sigpipe.cz> <150316090829.ZM15335@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150316090829.ZM15335@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) # schaefer@brasslantern.com / 2015-03-16 09:08:29 -0700: > On Mar 16, 9:08am, Roman Neuhauser wrote: > } > } but then i'm bound to miss replies. i don't want to subscribe to > } zsh-workers (yet)... > > We're pretty good about Cc'ing people when they ask to be. > > Everybody, please Cc Roman. well, i've subscribed to workers@ so, no need for cc's anymore. > } 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. > > I'm leaving this to PWS as he made the changes to configure.ac. I will > however note that I think --disable-site-fndir ought to do exactly that, > and the documentation blurb is what needs fixing. If the shell is being > configured for some kind of secure/embedded environment, removing all > access to locally added functions is perfectly reasonable. i don't have an opinion on which way it should be, but it needs to be consistent. > } > 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 > } > } zmodload or pkg-config? > > I meant a zmodload module. i know, i was hinting at the fact that a .pc file would suffice, maybe you'd find it "good enough". and there's the added benefit of it being the standard interface for this kind of things... -- roman