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 | man: Small cleanup for Command Line Editing (diff) | |
| download | dash-7f31919cba4b17af883db77f99bfa974f0821361.tar.gz dash-7f31919cba4b17af883db77f99bfa974f0821361.zip | |
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 { |