Global aliases, eval, and completion (Re: Expanding interactively aliases)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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