From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27878 invoked from network); 11 May 2004 20:39:28 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 11 May 2004 20:39:28 -0000 Received: (qmail 16544 invoked from network); 11 May 2004 20:38:52 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 11 May 2004 20:38:52 -0000 Received: (qmail 17146 invoked by alias); 11 May 2004 20:38:45 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7447 Received: (qmail 17137 invoked from network); 11 May 2004 20:38:44 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 11 May 2004 20:38:41 -0000 Received: (qmail 15987 invoked from network); 11 May 2004 20:38:41 -0000 Received: from sccrmhc12.comcast.net (204.127.202.56) by a.mx.sunsite.dk with SMTP; 11 May 2004 20:38:39 -0000 Received: from [10.0.1.3] (pcp01847643pcs.southk01.tn.comcast.net[68.47.245.210]) by comcast.net (sccrmhc12) with SMTP id <2004051120381101200rm9qde>; Tue, 11 May 2004 20:38:12 +0000 In-Reply-To: <040511192759.AA02456.SM@caleb.ins.cwru.edu> References: <19195.1084296895@csr.com> <040511181944.AA29985.SM@caleb.ins.cwru.edu> <3BDC51C1-A37B-11D8-B3B9-000A95B34D8E@blasted-heath.com> <040511192759.AA02456.SM@caleb.ins.cwru.edu> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D23F586-A38B-11D8-B3B9-000A95B34D8E@blasted-heath.com> Content-Transfer-Encoding: 7bit Cc: zsh-users@sunsite.dk, pws@csr.com From: Chris Jepeway Subject: Re: ksh Emulation Not Clearing Envariables Date: Tue, 11 May 2004 16:38:09 -0400 To: chet@po.CWRU.Edu X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: * X-Spam-Status: No, hits=1.5 required=6.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Hits: 1.5 >>> Variable assignments specified with special built-in utilities >>> remain >>> in effect after the built-in completes; this shall not be the case >>> with a regular built-in or other utility. >> >> Well...the variable assignment isn't occurring inside the function. >> It's outside, put into the environment before the function is called. > > Did you actually read the spec? Nope. I read the excerpts you provided, in the belief that you meant them to clearly support your statements. Shoot me for not catching that "[v]ariable assignments specified with special built-in utilities" meant "variable assignments preceding the command name." > Maybe reading the `Simple Commands' section will convince you: > > If no command name results, variable assignments shall affect the > current execution environment. Otherwise, the variable assignments > shall be exported for the execution environment of the command and > shall not affect the current execution environment (except for special > built-ins). Yup, sure, that's pretty definitive. What does it mean for X=one unset X Nothing, I suppose. unset will unset. Never in a million years would I have expected after X=one : for X to persist, while after X=one true X is unset. I wonder what the original purpose was, here. A "get out of jail free card" that let code implementing the special built-ins slide? These things (err, the SBIs) all look commands that *must* be implemented as built-ins, so perhaps in some implementation(s) there weren't the hooks to unset vars after they completed. POSIX just codified it so pre-existing implementations could remain compliant? >>> Chet Ramey, ITS, CWRU chet@po.cwru.edu >>> http://tiswww.tis.cwru.edu/~chet/ >> Me > Chet Ramey, ITS, CWRU chet@po.cwru.edu > http://tiswww.tis.cwru.edu/~chet/ Chris .