zsh-workers
 help / color / mirror / code / Atom feed
* bug: suffix alias and tabcompletion
@ 2016-06-21 19:39 Michael Gebhard
  2016-06-21 20:18 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Michael Gebhard @ 2016-06-21 19:39 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

Hey,

running the following commands and trying to complete the last line
by pressing tab produces a zsh taking up 100% cpu. Strace says the zsh
is alternatingly running mmap and mremap with increasing sizes in a loop.

zsh -f
touch foo.bar
alias -s bar='echo a &'
foo.bar fo

zsh version:
zsh 5.2 (x86_64-debian-linux-gnu)

Best regards,
Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: bug: suffix alias and tabcompletion
  2016-06-21 19:39 bug: suffix alias and tabcompletion Michael Gebhard
@ 2016-06-21 20:18 ` Bart Schaefer
  2016-06-22  9:01   ` Peter Stephenson
  0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 2016-06-21 20:18 UTC (permalink / raw)
  To: Zsh hackers list; +Cc: Michael Gebhard

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.

Normal aliases have a safeguard against the alias calling itself
recursively, but that must have been overlooked with suffix aliases.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: bug: suffix alias and tabcompletion
  2016-06-21 20:18 ` Bart Schaefer
@ 2016-06-22  9:01   ` Peter Stephenson
  2016-06-22 11:53     ` Peter Stephenson
  0 siblings, 1 reply; 4+ messages in thread
From: Peter Stephenson @ 2016-06-22  9:01 UTC (permalink / raw)
  To: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: bug: suffix alias and tabcompletion
  2016-06-22  9:01   ` Peter Stephenson
@ 2016-06-22 11:53     ` Peter Stephenson
  0 siblings, 0 replies; 4+ messages in thread
From: Peter Stephenson @ 2016-06-22 11:53 UTC (permalink / raw)
  To: Zsh hackers list

On Wed, 22 Jun 2016 10:01:59 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> 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.

You get it with ";", too, which is easier to test.

> 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.

After enough failed attempts, the right way presented itself.  We can
make this near enough to the normal alias case by attaching the alias to
be expanded (where we record the fact it's in use) to the argument, not
to the alias expansion itself.  The input stack that's recording this
doesn't care, and this makes it look pretty much exactly like the normal
case.

Obviously, this now gives "command not found" on the re-executed suffix
argument, which is the only sensible alternative to recursion.

pws

diff --git a/Src/lex.c b/Src/lex.c
index e36a01e..5ad3474 100644
--- a/Src/lex.c
+++ b/Src/lex.c
@@ -1842,10 +1842,11 @@ checkalias(void)
 	if ((suf = strrchr(zshlextext, '.')) && suf[1] &&
 	    suf > zshlextext && suf[-1] != Meta &&
 	    (an = (Alias)sufaliastab->getnode(sufaliastab, suf+1)) &&
-	    !an->inuse && incmdpos) {
-	    inpush(dupstring(zshlextext), INP_ALIAS, NULL);
+	    !an->inuse && incmdpos &&
+	    !(inbufflags & INP_ALSUFF)) {
+	    inpush(dupstring(zshlextext), INP_ALIAS, an);
 	    inpush(" ", INP_ALIAS, NULL);
-	    inpush(an->text, INP_ALIAS, an);
+	    inpush(an->text, INP_ALIAS, NULL);
 	    lexstop = 0;
 	    return 1;
 	}
diff --git a/Test/A02alias.ztst b/Test/A02alias.ztst
index 49e4756..1e09cd3 100644
--- a/Test/A02alias.ztst
+++ b/Test/A02alias.ztst
@@ -104,3 +104,9 @@
 >0
 ?(eval):2: invalid alias 'x=y' encountered while printing aliases
 # Currently, 'alias -L' returns 0 in this case.  Perhaps it should return 1.
+
+  alias -s mysuff='print -r "You said it.";'
+  eval 'thingummy.mysuff'
+127:No endless loop with suffix alias in command position
+>You said it.
+?(eval):1: command not found: thingummy.mysuff


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-06-22 11:53 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-21 19:39 bug: suffix alias and tabcompletion Michael Gebhard
2016-06-21 20:18 ` Bart Schaefer
2016-06-22  9:01   ` Peter Stephenson
2016-06-22 11:53     ` Peter Stephenson

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).