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: Fri, 02 Aug 2013 08:56:56 -0700	[thread overview]
Message-ID: <130802085656.ZM12566@torch.brasslantern.com> (raw)
In-Reply-To: <130801224901.ZM10731@torch.brasslantern.com>

On Aug 1, 10:49pm, Bart Schaefer wrote:
} Subject: Re: segfault in completion when using alias with \ as last charac
}
} 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.

I've tried a couple of different things and I think we need to take a
step back and figure out what OUGHT to be completed in this case.

I can stop it from segfaulting by tweaking we/wb in gotword(), but then
it completes strange inconsistent things depending on the comparative
lengths of the left=right sides of the alias.  And things get even
stranger if you have further aliases that remove the backslash again
(e.g. alias 'bar\ '=something).

One note:  In the case of the alias, gotword() is actually called more
than once, the first time after parsing 'foo' and the second after
parsing 'bar\'.  For completion purposes, the "correct" values are the
ones from the first call, because they describe the raw command line.
I think lexflags = 0 in gotword is supposed to have something to do
with this, but that doesn't kick in until the second call after the
damage has already been done.  (Also it seems like overkill, why are we
clearing ALL the flags here?)

Aside:  Why is gotword() marked mod_export?  Nothing calls it except
exalias() right there in lex.c.

Back to "what ought we do?" ...

The effect of the alias is going to be to turn the first two words on
the command line into a different single word which is then going to
be treated as the command name.  The only correct completion would be
the tail end of words that form a command after the alias expands,
that is, if "/usr/bin/bar none" were a command, then

% foo <TAB>
% foo none

is the only correct thing to complete, but to get that seemingly un-
quoted space to become part of the word "foo " is a nightmare (and an
edge case that doesn't seem worth a lot of effort).

Maybe we just should have stuck with having aliases always expand like
history does, way back when.


      reply	other threads:[~2013-08-02 15:57 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
2013-08-02 15:56     ` Bart Schaefer [this message]

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=130802085656.ZM12566@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).