From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20230 invoked from network); 26 Feb 2001 07:26:25 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Feb 2001 07:26:25 -0000 Received: (qmail 19008 invoked by alias); 26 Feb 2001 07:26:21 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13529 Received: (qmail 18997 invoked from network); 26 Feb 2001 07:26:20 -0000 From: "Bart Schaefer" Message-Id: <1010226072557.ZM4551@candle.brasslantern.com> Date: Mon, 26 Feb 2001 07:25:57 +0000 In-Reply-To: <200102210819.JAA17470@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Expanding interactively aliases" (Feb 21, 9:19am) References: <200102210819.JAA17470@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk Subject: Global aliases, eval, and completion (Re: Expanding interactively aliases) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 21, 9:19am, Sven Wischnowsky wrote: } Subject: Re: Expanding interactively aliases } } Oliver Kiddle wrote: } } > My real point is that the existing _expand appears to be expanding global } > aliases already. I wouldn't have expected this because -U is used when } > autoloading _expand. A quick check reveals that this is with the } > substitute style and is due to the fact that the aliases are expanded } > within eval. } } Now that you say that... I seem to have a very faint memory of a } discussion about this (not in _expand, I think, we had the problem } somewhere else). I think we found a solution which I can't think of } now and I don't know where to search for it either. You may be thinking of the thread that led to invention of "autoload -U" in the first place. There was another thread last March with the subject "Default fpath" that made a brief mention of the issue of aliases being expanded by "eval" and by "source", but that was a very brief sideline of the main topic. Of course it's entirely reasonable to _want_ aliases expanded by eval: foo() { if [[ $1 == --debug ]] then shift alias somecommand='print -u2 somecommand' fi # ... possibly much intervening code ... eval 'somecommand "$@"' } Because of the way functions are "compiled", using eval is the only way to create/use such a conditional alias. } > I don't think it is ideal that autoload -U functions are subject to } > aliases within eval and you could probably break a few bits of completion } > with certain global aliases. Yeah, particularly because _arguments does things like eval ws\=\( "${action[2,-2]}" \) and eval "action=( $action )" There are a number of other completion functions that use eval for similar purposes. } > Would it be easy to avoid this somehow? Having already implemented `autoload -U', we could now easily add a zsh option `noalias' akin to `noglob', and then add that to $_comp_options. Then completion functions that specifically wanted aliases could restore the `alias' option in the scope where they wanted it. Which incidentally leads me to wonder if bufferwords() doesn't have a potential bug in that it forces the C variable `noaliases' to 1 and 0 without saving/restoring it? I suppose as currently used `noaliases' can't possibly be anything other than 0 during bufferwords() ... } > The other solution would be a -U argument to eval which probably isn't } > a great idea because eval currently takes no options. I said exactly the same thing about "source -U" in the aforementioned year-ago thread. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net