From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Global aliases, eval, and completion (Re: Expanding interactively aliases)
Date: Mon, 26 Feb 2001 07:25:57 +0000 [thread overview]
Message-ID: <1010226072557.ZM4551@candle.brasslantern.com> (raw)
In-Reply-To: <200102210819.JAA17470@beta.informatik.hu-berlin.de>
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
next prev parent reply other threads:[~2001-02-26 7:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-21 8:19 Expanding interactively aliases Sven Wischnowsky
2001-02-21 8:42 ` Andrej Borsenkow
2001-02-21 10:50 ` Geoff Wing
2001-02-26 7:25 ` Bart Schaefer [this message]
2001-02-26 16:51 ` Global aliases, eval, and completion (Re: Expanding interactively aliases) Bart Schaefer
2001-02-26 23:03 ` Oliver Kiddle
2001-02-26 9:42 Sven Wischnowsky
2001-02-27 10:11 Sven Wischnowsky
2001-02-27 16:51 ` Bart Schaefer
2001-02-27 17:42 ` Bart Schaefer
2001-02-27 17:49 ` Andrej Borsenkow
2001-02-27 18:25 ` Bart Schaefer
2001-02-28 9:10 Sven Wischnowsky
2001-03-05 13:28 Sven Wischnowsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1010226072557.ZM4551@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).