diff options
| author | Harald van Dijk <harald@gigawatt.nl> | 2017-06-30 01:33:29 +0200 |
|---|---|---|
| committer | Herbert Xu <herbert@gondor.apana.org.au> | 2018-03-10 16:01:43 +0800 |
| commit | 7f31919cba4b17af883db77f99bfa974f0821361 (patch) | |
| tree | 363de67b2d4b3b6042626651529eb5a5b2b2a70f | |
| parent | 68dac4c5806438214708b5a3c08cc1585e12a7ae (diff) | |
| download | dash-7f31919cba4b17af883db77f99bfa974f0821361.tar.gz | |
input: Fix here-document redirection with vi/emacs on
On 27/06/17 16:29, Zando Fardones wrote:
> Hello,
>
> I think I've found a bug when using the here-document redirection in
> an interactive shell. What basically happens is that you can't see the
> command output if you set the "vi" or "emacs" options.
That's not quite what happens: the here-document contents got lost, so
there is no command output to see. Nice find.
The problem is that getprompt() is implicitly called by el_gets(). This
messes with the memory used by the parser to store the here-document's
contents. In the non-emacs/vi case, the prompt is explicitly written by
setprompt(), which wraps the getprompt() call in a
pushstackmark()/popstackmark() pair to restore the state so that parsing
can continue. But when getprompt() is called by el_gets(), it knows
nothing about this.
The whole call to el_gets() can be surrounded by another
pushstackmark()/popstackmark() pair to solve the problem, as attached.
Cheers,
Harald van Dijk
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
| -rw-r--r-- | src/input.c | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/src/input.c b/src/input.c index 06c08d4..e53423c 100644 --- a/src/input.c +++ b/src/input.c @@ -147,8 +147,12 @@ retry: static const char *rl_cp; static int el_len; - if (rl_cp == NULL) + if (rl_cp == NULL) { + struct stackmark smark; + pushstackmark(&smark, stackblocksize()); rl_cp = el_gets(el, &el_len); + popstackmark(&smark); + } if (rl_cp == NULL) nr = 0; else { |