From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30014 invoked from network); 9 Jun 2020 10:55:00 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 9 Jun 2020 10:55:00 -0000 Received: (qmail 7900 invoked by alias); 9 Jun 2020 10:54:46 -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: List-Unsubscribe: X-Seq: 46030 Received: (qmail 12234 invoked by uid 1010); 9 Jun 2020 10:54:46 -0000 X-Qmail-Scanner-Diagnostics: from mail-io1-f66.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25835. spamassassin: 3.4.4. Clear:RC:0(209.85.166.66):SA:0(-2.0/5.0):. Processed in 1.503957 secs); 09 Jun 2020 10:54:46 -0000 X-Envelope-From: mikachu@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.166.66 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8+fd9ywMdJPGwDz5AtO55fhZIu+6oTFZtM0l6yJ+yik=; b=ZFJOliPE6x7B+FvD4qig8WORGQagDMUbW4YV2NgD7uSdG+2PZAiU/jvywWTdP8Y/Kv oBIPNYW7VLXkd3uQSDNSctgJKPWAYCMUltGZaSNwl1pBMk6t4LHLDp4AsykgatI+ZJXD qPKNPylR+qE7LEwKrDysOh+/S/U4GSH+ejQYiiGP3+HYT/tDPIp2mtlx6Ojh+IVt4EZG wCo+DfyJ6WKa5f+mm5LmtKEc/4mKiWLnRB51cagtfif/pVntM3najC4I5YHIqpN4XPdn YJG8HySsRyWesXZdUY6LFz09Z2l6LtTLtifAkFPeR/ReC1dDWI0Y5/zYyuDOJg1vmc2Y fXWw== X-Gm-Message-State: AOAM530sIc2GRM0ftpAtYtEstm7r72GtH5fIPIL0gtgraNq6pQNLQGaJ y5MlBpElz5UMjuodqHulNJM3CI2NHR8Pl2uhvSEMCw== X-Google-Smtp-Source: ABdhPJx9oPi/DyTgqighbxFQUi6p9g+UduV/jdMDm1bYcy0qlmHvOdrGOMMS1bQRDMU1R6TFt4fYcfq5NMTRQOLFPYw= X-Received: by 2002:a05:6602:2e0e:: with SMTP id o14mr26238999iow.164.1591700051837; Tue, 09 Jun 2020 03:54:11 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20200609075728.3c3941d8@tarpaulin.shahaf.local2> References: <20200605015338.1347787-1-sandals@crustytoothpaste.net> <20200605015338.1347787-2-sandals@crustytoothpaste.net> <20200605204144.GD6569@camp.crustytoothpaste.net> <20200609075728.3c3941d8@tarpaulin.shahaf.local2> From: Mikael Magnusson Date: Tue, 9 Jun 2020 12:54:10 +0200 Message-ID: Subject: Re: [PATCH v2] exec: run final pipeline command in a subshell in sh mode To: Daniel Shahaf Cc: Peter Stephenson , zsh-workers@zsh.org Content-Type: text/plain; charset="UTF-8" On 6/9/20, Daniel Shahaf wrote: > Peter Stephenson wrote on Sun, 07 Jun 2020 18:24 +0100: >> On Sun, 2020-06-07 at 09:55 -0700, Bart Schaefer wrote: >> > On Fri, Jun 5, 2020 at 1:42 PM brian m. carlson >> > wrote: >> > > >> > > I will tell you that as a practical matter, nobody writing code for >> > > sh >> > > expects the last command not to be run in a subshell and consequently >> > > lots of code is practically broken in this case with zsh as /bin/sh. >> > > >> > >> > I believe you, but would be curious to see an example. >> > >> > For what it's worth, I'm not opposed to this patch. I think it's >> > pretty unlikely that anyone is invoking zsh as sh and still expecting >> > to be able to (for example) pipe into read to set variables in the >> > current shell. >> >> Yes, since I'm still here, that's my position too. >> >> Our general position on consistency is that we'll try our best to >> keep native mode compatible, while with sh compatibility we'll >> try to be like other shells and not worry so much about what zsh >> used to do. > > This being the case, I'm happy to defer to consensus. I won't object > to an entry in the list of incompatibilities in README, though. > > I can't speak for Mikael, of course. I was only objecting to the commit message in the first place :). I think the arguments for including it are not very convincing but I don't really have any at all for not including it. Surely it must be very rare to run something like foo | shellfunction and *depend* on shellfunction not setting any global parameters? Why would you make shellfunction set global parameters in the first place if you depend on them not being set? And then only when being piped to? It seems so strange to me. Anyway, those are just arguments against the sanity of shellscript writers, not against the inclusion of the patch. -- Mikael Magnusson