From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4716 invoked from network); 25 Mar 2001 16:36:40 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Mar 2001 16:36:40 -0000 Received: (qmail 25700 invoked by alias); 25 Mar 2001 16:36:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13749 Received: (qmail 25609 invoked from network); 25 Mar 2001 16:36:22 -0000 Sender: opk Message-ID: <3ABE0E39.B74CAB72@u.genie.co.uk> Date: Sun, 25 Mar 2001 16:26:49 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.18 i586) X-Accept-Language: en MIME-Version: 1.0 To: Zsh workers Subject: Re: Moving completion functions References: <3ABA72A9.EB9C68FC@u.genie.co.uk> <010322162918.ZM21205@candle.brasslantern.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bart wrote: > Long, long ago it was decided that it was a bad idea to import FPATH. > So long ago that it's not in the zsh-workers archive, unfortunately. > Probably has something to do with the fact that its a huge security > hole, i.e., you can cause some other user's shell to inherit a trojan > via any function you can guess he might autoload. That's a good point. I have a horrible feeling you mentioned that before sometime. It made me wonder though: surely PATH is similar. I've always tended to add to the path in my .zshrc so this makes me wonder if it wise to set it fully and in .zshenv for similar security reasons. > } As I said with the original suggestion, there could be a variable set > } to point to the base of the installed functions. > > A parameter set how? By hardwiring it at compile time? I suppose that > the zsh/complete module could define one. Yes, or in the same way as how $fpath is set. I've used things like ${fpath[(r)*Core]:-$fpath[(r)*/functions]} in a few places (such as my zrecompile script) to get at this directory so it might be useful anyway. I did a bit of thinking last week and as for the whole suggestion about setting $fpath, I think you've convinced me that the current situation is probably just as good/bad as my suggestion. I think it would definitely be worse if we ended up supporting both ways of doing it with a configure option so I won't mention it again. So I suggest we leave it as it is and I shut up. > } Do we need to account for kshautoload though? > The only way is to "zcompile -z" the whole thing and then put the .zwc > file in fpath. This has been mentioned before (it may even be in the > docs somewhere). I couldn't see it in the docs but these things aren't so easy to find. If it gets asked much, we can always add it to the FAQ. As for sourcing compinit, I suppose it might have a performance implication. I just felt that sourcing is more natural for what it is doing and is possibly an easier concept for new users to understand. >>From the perspective of my own use of zsh, I don't really care how compinit does its stuff. I'm not too keen on us complicating compinit so that sourcing it is an option but with autoload being the method mentioned in the manual. Bart Schaefer wrote: > > I would include harden, checkmail, mere, and definitely zed as "useful > functions which many people might want to use," but proto is marginal > (how many people code in C with exactly Paul Falstad's style?) and to > autoload all those those trivial one-liners is IMO a waste. Sorry, I didn't really know what proto was but assumed it was something more general and so more useful. > It's too big to reasonably put in compctl-examples and remains relevant fair enough. Again I've never used it and just glanced to see what it did. > > > Functions/Misc/run-help Functions/Misc # Add #autoload line? > > > That's why there's a `?' at the end of my comment. So, leave run-help > as it is. Er? I saw the ? and meant my comment as an answer but probably got the tone of it wrong. In some ways, I wonder that #autoload as a wider feature might be useful. > I'd actually rather split compctl-examples up into smaller files and put > them all in Functions/Compctl, but I suppose we're trying to discourage > use of compctl ... That's not a bad idea. They'd be out of the way in the Compctl directory so I don't think it would be too much of an encouragement. More functions in Compctl would better justify its existence. I've also been convinced that compctl still serves a purpose. > The main thing I want to do with the example startup files is to add a > batch of comments, possibly in all-caps, telling system administrators > NOT to drop these files into /etc/z*. And maybe even put a "return 0" > at the top of each file just in case some nimrod copies them to /etc/ > without looking at them. I would definitely agree with that. Oliver