From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-7445-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 24928 invoked from network); 11 May 2004 18:48:19 -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 18:48:19 -0000
Received: (qmail 21624 invoked from network); 11 May 2004 18:46:05 -0000
Received: from sunsite.dk (130.225.247.90)
  by a.mx.sunsite.dk with SMTP; 11 May 2004 18:46:05 -0000
Received: (qmail 26682 invoked by alias); 11 May 2004 18:45:16 -0000
Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 7445
Received: (qmail 26619 invoked from network); 11 May 2004 18:45:14 -0000
Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86)
  by sunsite.dk with SMTP; 11 May 2004 18:45:11 -0000
Received: (qmail 18001 invoked from network); 11 May 2004 18:45:00 -0000
Received: from sccrmhc13.comcast.net (204.127.202.64)
  by a.mx.sunsite.dk with SMTP; 11 May 2004 18:44:57 -0000
Received: from [10.0.1.3] (pcp01847643pcs.southk01.tn.comcast.net[68.47.245.210])
          by comcast.net (sccrmhc13) with SMTP
          id <2004051118442901600t22fhe>; Tue, 11 May 2004 18:44:29 +0000
In-Reply-To: <040511181944.AA29985.SM@caleb.ins.cwru.edu>
References: <19195.1084296895@csr.com> <040511181944.AA29985.SM@caleb.ins.cwru.edu>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3BDC51C1-A37B-11D8-B3B9-000A95B34D8E@blasted-heath.com>
Content-Transfer-Encoding: 7bit
Cc: zsh-users@sunsite.dk,
 pws@csr.com
From: Chris Jepeway <jepeway@blasted-heath.com>
Subject: Re: ksh Emulation Not Clearing Envariables
Date: Tue, 11 May 2004 14:44:28 -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=BAYES_44,RCVD_IN_SORBS 
	autolearn=no version=2.63
X-Spam-Hits: 1.5

>>> POSIX wants the envariable to persist across invocations
>>> of the function "e"?  That seems...counter-intuitive.
>>
>> I can't find it in POSIX now, but it's controlled by the option
>> posix_builtins.  We could turn that off for ksh, but I'd like to know  
>> if
>> we really ever need to have it on by default.
>
> http://www.opengroup.org/onlinepubs/009695399/utilities/ 
> xcu_chap02.html#tag_02_09_05
>
> Where we see
>
> 	When a function is executed, it shall have the syntax-error and
> 	variable-assignment properties described for special built-in
> 	utilities in the enumerated list at the beginning of Special Built-In
> 	Utilities.
>
> One of those properties is:
>
> 	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.
Had the function looked like:

	e() {
		X=one
		echo $X
	}

	e ; echo "[$X]"

I would have expected to see

	one
	[one]

However, with this:

	e() {
		echo $X
	}

	X=one e ; echo "[$X]"

I'd expect to see

	one
	[]

I don't see how the spec can be read to mean "envariables
poked into a command shall persist across command invocations
when that command is a shell function."

> Chet Ramey, ITS, CWRU    chet@po.cwru.edu     
> http://tiswww.tis.cwru.edu/~chet/
Chris.