From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11718 invoked by alias); 24 Jan 2017 22:24:53 -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: 40411 Received: (qmail 12254 invoked from network); 24 Jan 2017 22:24:53 -0000 X-Qmail-Scanner-Diagnostics: from mercury.zanshin.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(64.84.47.142):SA:0(-0.0/5.0):. Processed in 1.047547 secs); 24 Jan 2017 22:24:53 -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=SPF_PASS 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: pass (ns1.primenet.com.au: SPF record at ipost.com designates 64.84.47.142 as permitted sender) Date: Tue, 24 Jan 2017 14:24:17 -0800 (PST) From: Bart Schaefer Reply-To: Bart Schaefer To: "Zsh Hackers' List" Subject: Re: "VAR=foo export VAR" no longer works in zsh emulation In-Reply-To: <20170124175258.78b0554e@pwslap01u.europe.root.pri> Message-ID: References: <20170124135037.06081eb1@pwslap01u.europe.root.pri> <20170124163235.7cfbc4f6@pwslap01u.europe.root.pri> <20170124175258.78b0554e@pwslap01u.europe.root.pri> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) X-Face: "f/X=UCVgd*^c>+x(gMq0at?e:woX+;'snkkRzc3SX<0AZ (/PS4.M2hzGS9X:Qj]at_H/%a9K}:-eS<"v_7vX84PG9Bf Zpb`wI!I4geY=or+nWq`3CX`oq&TJR;g^ps|7(MH?jh;bs %vHJfCh5>a*6Re5m|Bidja\\o]>n\A)ib1:yX*T`zR(*h~ %tOw<~!D9{e6h!8M2:d8G2@K>y^1I_Vdy\d\MYe]z7c MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 24 Jan 2017, Peter Stephenson wrote: > It looks up to 5.2 you don't need the option, and this changed in the > commit below. > > So it's less sh compatibility, as it still works there, and more > backward compatilibity in zsh. > > pws > > commit c8de0af35935602370cc79193d0e0d53971250d4 > Author: Barton E. Schaefer > Date: Mon Sep 19 00:25:13 2016 -0700 > > 39381: handle save/restore of variable values when "typeset"-related reserved words are prefixed by an assignment Hrm, this is a bit ugly. It might be possible to fix this for "export" by a special-case on the command name, but it's going to be nearly impossible to make "typeset -x" behave equivalently, because the save/restore is generic in exec.c where we barely know what command we're about to run, and we don't learn that we're exporting until the depths of bin_typeset(), nor propagate that back out in any way.