From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12106 invoked by alias); 20 Jul 2013 22:16:28 -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: 31548 Received: (qmail 17755 invoked from network); 20 Jul 2013 22:16:22 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 Received-SPF: neutral (ns1.primenet.com.au: 209.85.215.173 is neither permitted nor denied by SPF record at ntlworld.com) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-proxyuser-ip:message-id:x-authentication-warning:from:to:subject :in-reply-to:date:x-gm-message-state; bh=3XS4qpOHWCs528YPaGvoH7FMRnKafpEKv2kLobfF3fs=; b=genmlB+ZhWGMNZ0+FQOxAkgU3e2Lmx9btphJDA+Lvx7I97Tgyl3ftSrutSiSaFsJXG G7xFL9ocD4NtdqIgbCx2mTFP6SFwFhls3FYHJIL8wWvUc1sLn7Cg4UGhyn9TnrpgwnvT p/mQDrPYu6VP+zf4PXUH/NCnMsx0+1d0nYrtRk0QXHFpiw5MgQwxyLTkLQnQNVUoa/1B g/P/xzLdHlZ164KJktmgztMy/a8975klGFEaah948VLNJZNfgaNVydH1XefWRIZ1zJhO elJMzTJBpmlWGmkmCc8Sj6ouQOTj3drhspUbe0hCmwKUaoap7THHRLzfQG2uL0dT/ZYR dwXw== X-Received: by 10.15.82.132 with SMTP id a4mr21547185eez.107.1374358576165; Sat, 20 Jul 2013 15:16:16 -0700 (PDT) X-ProxyUser-IP: 86.6.30.159 Message-Id: <201307202216.r6KMGBib009836@pws-pc.ntlworld.com> X-Authentication-Warning: pws-pc.ntlworld.com: pws owned process doing -bs From: Peter Stephenson To: "zsh-workers@zsh.org" , pws@pws-pc.ntlworld.com Subject: Re: bug with eval, proc-subst and pipes In-Reply-To: Message from Bart Schaefer of "Sat, 20 Jul 2013 13:57:59 PDT." Date: Sat, 20 Jul 2013 23:16:11 +0100 X-Gm-Message-State: ALoCoQnVHVqoHz/PXhP/1fGZT43ivHHo9IxHwEIfQtP4u4EjY5b8sQnsPL+JphkoKnw3FSjvfCyd Bart Schaefer wrote: > Something doesn't look right about this patch, but I've only looked at the > patch itself, not at the context (I'm away from my usual computers at the > moment). The #ifndef lines seem to put both a functional and a no-op > version of closedumps() in the same not-FD_CLOEXEC context? And if > closedumps() was a no-op with FD_CLOEXEC before (?) then would it change > anything to remove it at the point of call? It's a no-op in the not-USE_MMAP case for dumps. In that case there was no file descriptor in the first place, so closedumps() wasn't needed. It would have been more logical not to define it and mark its use as #if defined(USE_MMAP) && !defined(FD_CLOEXEC) but I had no reason to change the way the not-USE_MMAP case was implemented, particularly since it's not the case that gets compiled on my or most modern systems. So it's a minor inconsistency with no effect. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/