zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org
Subject: Re: Completion in empty double-quotes generates error
Date: Tue, 10 May 2016 18:40:31 +0000	[thread overview]
Message-ID: <20160510184031.GA27856@tarsus.local2> (raw)
In-Reply-To: <160406121053.ZM31877@torch.brasslantern.com>

Bart Schaefer wrote on Wed, Apr 06, 2016 at 12:10:53 -0700:
> On Apr 2, 11:18am, Bart Schaefer wrote:
> } Subject: Re: Completion in empty double-quotes generates error
> }
> } What would one expect to be completed with the cursor on the "2"?  The
> } -redirect- special context is for what comes *after* the operator.  I
> } can think of only two choices:
> } 
> } 1.  Complete as if there were an implicit space to the right of the
> }     cursor.  This makes some sense because "2>" is treated as the same
> }     single token as ">" all alone.
> } 
> } 2.  Treat it as an error and simply fail.
> } 
> } Patch below does this
> 
> More specifically, it attempted to do (1).  However, this situation is
> really nasty -- get_comp_string() repeatedly calls the lexer looking for
> the word containing the cursor, but because the lexer treats redirections
> as positionally insignficant, there literally is no word containing the
> cursor, so get_comp_string() keeps looking and finds the NEXT word (or
> the end of the input), which places both wb and we beyond zlemetacs.
> 
> It gets worse still with "{myfd}>", and worse again when completing in
> the whitespace between a word and a redirection (because in that last
> situation it's correct for the redirection token to be ignored).
> 
> I'm still not entirely sure that the below is correct, i.e. that the
> right things would happen if the "Should" comments were replaced with
> the appropriate actual code.  But this at least handles more cases than
> the previous situation.

'tmux new <TAB>' segfaults:

    $ zsh -f
    % echo $ZSH_PATCHLEVEL
    zsh-5.2-dev-1-130-g98f670c
    % autoload compinit
    % compinit
    % tmux new <TAB>5: compcore.c:1657: expecting 'x' at offset -7 of "x"
    
    Program received signal SIGSEGV, Segmentation fault.
    0x00007ffff5a030da in check_param (s=0x7ffff7f90188 "x", set=0, test=1) at compcore.c:1108
    1108		if (*p == String || *p == Qstring) {
    (gdb) p p
    $1 = 0x7ffff7f8ffff <error: Cannot access memory at address 0x7ffff7f8ffff>
    (gdb) bt
    #0  0x00007ffff5a030da in check_param (s=0x7ffff7f90188 "x", set=0, test=1) at compcore.c:1108
    #1  0x00007ffff5a0451f in set_comp_sep () at compcore.c:1677
    #2  0x00007ffff59fece5 in bin_compset (name=0x7ffff7f900d0 "compset", argv=0x7ffff7f900e0, ops=0x7ffffffe4160, func=0) at complete.c:1031

It bisects to 38248 (which I'm replying to).

I didn't have any tmux sessions/processes running while I was
reproducing the bug.

Cheers,

Daniel

P.S. With latest master, «sh -c <TAB>» also segfaults; on the other
hand, after «compdef _cmdstring f», «f <TAB>» doesn't segfault.

> The change in gotword() is necessary but of a little concern.  AFAICT
> we only care about wb when examining the word under the cursor, so it
> shouldn't hurt to skip updating it when doing so would violate the
> wb <= zlemetacs <= we constraint, but there may be some corner case I
> haven't tried that depends on the old behavior.
> 
> 
> diff --git a/Src/Zle/zle_tricky.c b/Src/Zle/zle_tricky.c
> index b1709c1..1d4e1d2 100644
> --- a/Src/Zle/zle_tricky.c
> +++ b/Src/Zle/zle_tricky.c
> @@ -1161,6 +1161,7 @@ get_comp_string(void)
>      inpush(dupstrspace(linptr), 0, NULL);
>      strinbeg(0);
>      wordpos = cp = rd = ins = oins = linarr = parct = ia = redirpos = 0;
> +    we = wb = zlemetacs;
>      tt0 = NULLTOK;
>  
>      /* This loop is possibly the wrong way to do this.  It goes through *
> @@ -1238,6 +1239,20 @@ get_comp_string(void)
>  	    /* Record if we haven't had the command word yet */
>  	    if (wordpos == redirpos)
>  		redirpos++;
> +	    if (zlemetacs < (zlemetall - inbufct) &&
> +		zlemetacs >= wordbeg && wb == we) {
> +		/* Cursor is in the middle of a redirection, treat as a word */
> +		we = zlemetall - (inbufct + addedx);
> +		if (addedx && we > wb) {
> +		    /* Assume we are in {param}> form, wb points at "{" */
> +		    wb++;
> +		    /* Should complete parameter names here */
> +		} else {
> +		    /* In "2>" form, zlemetacs points at "2" */
> +		    wb = zlemetacs;
> +		    /* Should insert a space under cursor here */
> +		}
> +	    }
>          }
>  	if (tok == DINPAR)
>  	    tokstr = NULL;
> diff --git a/Src/lex.c b/Src/lex.c
> index d4132fe..25b372a 100644
> --- a/Src/lex.c
> +++ b/Src/lex.c
> @@ -1789,9 +1789,13 @@ parse_subst_string(char *s)
>  static void
>  gotword(void)
>  {
> -    we = zlemetall + 1 - inbufct + (addedx == 2 ? 1 : 0);
> -    if (zlemetacs <= we) {
> -	wb = zlemetall - wordbeg + addedx;
> +    int nwe = zlemetall + 1 - inbufct + (addedx == 2 ? 1 : 0);
> +    if (zlemetacs <= nwe) {
> +	int nwb = zlemetall - wordbeg + addedx;
> +	if (zlemetacs >= nwb) {
> +	    wb = nwb;
> +	    we = nwe;
> +	}
>  	lexflags = 0;
>      }
>  }
> 


  reply	other threads:[~2016-05-10 18:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 18:06 Bart Schaefer
2016-04-01  5:36 ` Daniel Shahaf
2016-04-02  1:18   ` Bart Schaefer
2016-04-02  3:29     ` Daniel Shahaf
2016-04-02  6:20       ` Bart Schaefer
2016-04-02 18:18         ` Bart Schaefer
2016-04-06 19:10           ` Bart Schaefer
2016-05-10 18:40             ` Daniel Shahaf [this message]
2016-05-10 20:13               ` Bart Schaefer
2016-05-10 21:00                 ` Bart Schaefer
2016-05-11 16:21                   ` Daniel Shahaf
2016-05-10 21:29                 ` Mikael Magnusson

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=20160510184031.GA27856@tarsus.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=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).