zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: segfault in completion when using alias with \ as last character
Date: Thu, 01 Aug 2013 22:49:01 -0700	[thread overview]
Message-ID: <130801224901.ZM10731@torch.brasslantern.com> (raw)
In-Reply-To: <130801092508.ZM8575@torch.brasslantern.com>

On Aug 1,  9:25am, Bart Schaefer wrote:
}
} On Aug 1,  4:45pm, torstenschmits@gmail.com wrote:
} }
} } alias foo='bar\'
} } foo <tab>
} } -> segfault.
} 
} Src/Zle/zle_tricky.c:668: BUG: 0 <= wb <= zlemetacs <= we is not true!

The problem appears to be somewhere in the lexer, rather than in the
completion system itself.  Tracing through this, if I use e.g.:

% alias foo='echo'
% foo <TAB>

then in lex.c:gotword() the value of wordbeg is 1, and wb is correctly
calculated.

With foo='bar\', however, wordbeg is 6 so wb ends up negative, and it's
all downhill from there.

The upshot seems to be that the trailing backslash in the expanded
alias causes the space after "foo" on the command line to be consumed
as part of the command word.  In effect, the completion system thinks
the completion is at the beginning of the second word, but the lexer
says no, completion is actually in the middle of the first word, and
docomplete() isn't prepared to deal with that dissonance.

This is handled for history by simply expanding it in place and then
refusing to complete anything if the command line changed, but in the
case of aliases we try try to complete as if the alias were expanded
without actually altering the command line to reveal it.

You can see that the segfault does not happen if there are TWO spaces:

% alias foo='bar\'
% foo  <TAB>
Completing file
Src/               Doc/               config.modules     Config/          
Test/              Makefile           config.modules.sh  Etc/             
config.log         stamp-h            config.status*     config.h         

It seems wrong for gotword() to report wb < 0, but just asserting that
wb = 0 when it computes less than zero still triggers the BUG: warning
(though it correctly causes completion to find no matches and instead
e.g. attempt correction), so there must be other tweaking needed to
get wb, we, zlemetall, and zlemetacs all set properly in this case.


  reply	other threads:[~2013-08-02  5:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01 14:45 torstenschmits
2013-08-01 16:25 ` Bart Schaefer
2013-08-02  5:49   ` Bart Schaefer [this message]
2013-08-02 15:56     ` Bart Schaefer

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=130801224901.ZM10731@torch.brasslantern.com \
    --to=schaefer@brasslantern.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).