From patchwork Thu Jun 29 23:33:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Harald van Dijk X-Patchwork-Id: 9818095 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id C5D7A6020A for ; Thu, 29 Jun 2017 23:33:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A990D28526 for ; Thu, 29 Jun 2017 23:33:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9CB3328534; Thu, 29 Jun 2017 23:33:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI, T_TVD_MIME_EPI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AE1EB28526 for ; Thu, 29 Jun 2017 23:33:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751782AbdF2Xdf (ORCPT ); Thu, 29 Jun 2017 19:33:35 -0400 Received: from home.gigawatt.nl ([83.163.3.213]:43546 "EHLO home.gigawatt.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751579AbdF2Xde (ORCPT ); Thu, 29 Jun 2017 19:33:34 -0400 Received: from [IPv6:2001:980:4809:1:80c4:5e56:8654:bf23] (unknown [IPv6:2001:980:4809:1:80c4:5e56:8654:bf23]) by home.gigawatt.nl (Postfix) with ESMTPSA id 8B2755400845; Thu, 29 Jun 2017 23:33:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 home.gigawatt.nl 8B2755400845 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigawatt.nl; s=default; t=1498779212; bh=mQyudSx8rxb3tIfl7hzEJEVlOD4eKHY8G6YOgmSqgBc=; l=1750; h=Subject:To:References:From:Date:In-Reply-To:From; b=KtwRDUHoucurC3iSvyyjCo8ZEP8tRdYQ2+1FEAbZq7ATngi85po79pK3eCPR/PDdO GD5HlTQZyyecxsCSyq1IC2SJVHIKUuZv0fvW8BiLw+VU8uUyobhdvp6eCOhn0SWC40 blm12uml4mvEXG+cnE5d+UPegBiOfedSb27HvCLc= Subject: Re: [BUG] Here-document redirection with vi/emacs on To: Zando Fardones , dash@vger.kernel.org References: From: Harald van Dijk Message-ID: Date: Fri, 30 Jun 2017 01:33:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Sender: dash-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dash@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- 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 {