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 /src/bltin | |
| 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>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions