Re: Crash when capturing command output in completion

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Fri, 16 Jan 2015 08:18:43 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jan 16, 12:57pm, Peter Stephenson wrote:
> }
> } Only very lightly tested and so probably partial fix --- however, I'll
> } commit this because (i) I'm fairly sure it's going in the right
> } direction (ii) it does work in some cases and hence the shell is less
> } crash-prone (iii) I get to insert a whiny message about the horrible
> } interface which always improves my morale.
> 
> OK, this changed something -- I don't get a crash any more (though I
> probably should as there is obviously a rogue pointer) but *without*
> -DZSH_OLD_SKIPCOMM I get this:
> 
> schaefer<501> echo ÿÿÿÿÿÿÿÿ$(ls)
> Completing all expansions
> ÿÿÿÿÿÿÿÿ$(ls)
> Completing original
> $(ls)

That's not happening here.  I had no problem with inserting the output
of ls in Src word by word, though there was some evidence of display
funnies when it tried to insert the complete set of words as an
expansion.

If it still happens after rebuilding from scratch, could you see if it's
related to what ls is actually outputting or some completion option?

> This has to mean it's a difference between hgetc() and lex_add_raw()
> or whatever; I don't really follow yet what's happening with those
> new routines.

The sole purpose of lex_add_raw() is to track the input buffer to be
copied back raw as the contents of the $(...).  Meanwhile, on top of
that, it's being parsed, but that's no use to us later as we need the
string for the command line argument.

The complexity comes when the input tracked in this way (tokstr_raw)
gets reinstalled in the normal string (tokstr) when we get to the end of
the parentheses.  From then on it's just a string again, until the
$(...) is actually executed.

pws