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