From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5622 invoked by alias); 21 Jul 2016 03:40:19 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 38899 Received: (qmail 4327 invoked from network); 21 Jul 2016 03:40:19 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f181.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.192.181):SA:0(0.0/5.0):. Processed in 0.159277 secs); 21 Jul 2016 03:40:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=AScyXhwQ+48s8ODbA9UFOD8mg7UpyE4AhqUQR0yRCsM=; b=wPWJDbUpM1xaizlFpPh85WDy8ux3dVJ14ycjSeBRcNgU1vUrf02rrI0ARjxD3RDweh xgFHdgjASmSnK8X1WVsnoi1tht/Nl7UDcc8O3txPUNASJPzlErlPnoly3uxM1xjbvlRM qt7Dmdb5WitfnqK/apVPiF7XxAo7sys95E39GJkuyauz0EdL6NAOEFBbCaJNgIePbfL2 And4Z31ZkyLWSVMgyYk6W4qTZ4a+ITKadEjHTaRjbgw2ifbhpkMYxifCn8BA/xXioZs7 QMxV5tJ3RPTGVYqVR9DkQ3Rx3gSezVMShXQJJ46JjEpIlVtt+N4rB4WqX89uxqNK/kac dzNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=AScyXhwQ+48s8ODbA9UFOD8mg7UpyE4AhqUQR0yRCsM=; b=h91JZwI1gJs6i4jGYw/cXV8Ktj7+b8uLRD/0utkSMrvjGRKMmiDMysOd6Wjc/wpYE1 sBij2AfvXTYibkaoQ0EObkztvaT7dcJefrBqMtls0EI75ZQkUIijkRgNgPdT7RdWUrYW 9dp+W8RDdRz0TGgy3S7CXeNsZlJc/SGt+7zfCJJTHOSDodeBpfyPWUEwhEHQBcgxsixL v/xsHZ0CH/BAAkDwoSRLgqMqb9RDUQbwlaOAOg8qXFTDKmsk75+Tu8ZJQM9nqrGjsnKv XwV+lS0S0a+7zQjw4/pKG1Ex/pMvAfvuWc7IMz7wMi+bqcwSP/t/xsbN063Zh+S98xcq gO9Q== X-Gm-Message-State: ALyK8tJEnubMb5k7XFY5iuDyPOHNOUKppR3iAZ6rZVLtISv1a0m7C89DqcN6mYoAoq4Mqg== X-Received: by 10.98.79.140 with SMTP id f12mr62740831pfj.161.1469072412101; Wed, 20 Jul 2016 20:40:12 -0700 (PDT) From: Bart Schaefer Message-Id: <160720204047.ZM27592@torch.brasslantern.com> Date: Wed, 20 Jul 2016 20:40:47 -0700 In-Reply-To: <20160720132113.1d70a4c0@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: use of "less" in function and interrupt" (Jul 20, 1:21pm) References: <20160720113633.GA17431@zira.vinc17.org> <20160720132113.1d70a4c0@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: use of "less" in function and interrupt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jul 20, 1:21pm, Peter Stephenson wrote: } Subject: Re: use of "less" in function and interrupt } } On Wed, 20 Jul 2016 13:36:33 +0200 } Vincent Lefevre wrote: } > With zsh 5.2, if I type: } > } > zira% tless() { less "$@"; } } > zira% sleep 5 | tless } > } > then "less" is left stopped in background after I type a key. After you type ^C, you mean? } Interestingly, I can get this to happen with } } sleep 5 | { less } In both cases it works as expected provided that "sleep 5" has exited, so you have to interrupt the sleep. } but not } } sleep 5 | ( less ) } } I'm not sure what that says about job control, which I've never really } understood, but the two cases should be very close as in the second the } shell knows it's about to exit and should exec less without an extra } fork. I believe the difference is that in both the functin case and the curly brackets case you have a "current shell job" at the tail of the pipeline; "less" is a subjob of that current shell job. In the other cases you have a true external job at the end of the pipeline; you're correct that the subshell exec's less, so it's equivalent to piping directly to less. } I'm guessing that in the failing cases less is somehow being } detached from the terminal while in the other cases it isn't and, when } you quit less, normal service is resumed. Pretty much, yes. I think what's happening is that the "current shell job" is noticing that a ^C was delivered and therefore stops waiting for its subjobs, not noticing that that "less" has ignored the signal and continued on anyway. Probably there's some point where the one last wait is needed, within the cleanup of jobs in the current shell, to make sure that all the subjobs really did go away. I suspect this to be related to the breakup of errflag into ERRFLAG_ERROR and ERRFLAG_INT.