zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: bug: suffix alias and tabcompletion
Date: Wed, 22 Jun 2016 10:01:59 +0100	[thread overview]
Message-ID: <20160622100159.1d82792f@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <CAH+w=7YdV_LFUghpueqbjRHWyhzEA8iDarE=FGG1BSk2Fr+s0w@mail.gmail.com>

On Tue, 21 Jun 2016 13:18:21 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Tue, Jun 21, 2016 at 12:39 PM, Michael Gebhard
> <michael.gebhard@fau.de> wrote:
> >
> > running the following commands and trying to complete the last line
> > by pressing tab produces a zsh taking up 100% cpu.
> >
> > zsh -f
> > touch foo.bar
> > alias -s bar='echo a &'
> 
> It's not (just) completion; attempting to run the command "foo.bar"
> produces a similar infinite loop.  The alias has expanded to "echo a &
> foo.bar" which then recursively expands "foo.bar" (because after the
> "&" it is in command position again) and off we go.  The "touch
> foo.bar" isn't required.

This is different from a normal alias because in that case the original
text is completely removed; you can only encounter the (normal or
global) alias again while expanding the alias, which we detect, or
after, which is a completely different set of input triggering the
expansion so there's no recursion.

In this case, the argument foo.bar appears again *after* the alias has
been expanded fully because the alias is inserted before it.  By the
time we get to foo.bar again as the argument, the trace of alias
expansion has been removed --- we've just got the resulting fully
expanded text "echo a &" and no more alias.

The nearest parallel to this case with normal aliases is this:

alias foo='echo a &'
% foo foo
[1] 3423
a
[2] 3424
% 
[1]  - done       echo a
% a

[2]  + done       echo a

You'll see the underlying expansion behaviour is the same --- both
aliases get expanded.  This is long-standing and I assume is regarded as
OK.

I suppose we'd need some way of marking something as having had a suffix
alias expanded before it, and then we'd need to reset that flag if we
encountered something not at the start of that input that was in command
position so we could expand a new suffix alias.

However, I don't think it's quite as simple as the two separate tests
- when expanding a suffix alias, set a lexical flag to say no more
suffix aliases;
- reset that flag any time you reach a new command position

because in the problem case we have reached a new command position and
don't want to reset the flag.  So there's some subtle ordering to sort
out.

pws


  reply	other threads:[~2016-06-22  9:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-21 19:39 Michael Gebhard
2016-06-21 20:18 ` Bart Schaefer
2016-06-22  9:01   ` Peter Stephenson [this message]
2016-06-22 11:53     ` Peter Stephenson

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=20160622100159.1d82792f@pwslap01u.europe.root.pri \
    --to=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /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).