ksh Emulation Not Clearing Envariables

ksh Emulation Not Clearing Envariables

[Chris Jepeway]

I ran into some trouble with ksh emulation when trying to get zsh
to work with a ksh88 script.  Here's a smallish test case that
illustrates the problem:

	emulate ksh

	function e {
		env | egrep ^X
	}

	X=one e <<-EEK
       	Oy
	EEK

	e

I'd expect the output to be

	X=one

Instead, I see

	X=one
	X=one

Without ksh emulation enabled, I see the expected output.
This, with zsh-4.2.0.

This is a bug, right?  If so, should I file a report @ sourceforge.net?

Chris <jepeway@blasted-heath.com>.

Re: ksh Emulation Not Clearing Envariables

[Bart Schaefer]

On Sat, 8 May 2004, Chris Jepeway wrote:

> I'd expect the output to be
> 
> 	X=one
> 
> Instead, I see
> 
> 	X=one
> 	X=one
> 
> Without ksh emulation enabled, I see the expected output.
> 
> This is a bug, right?

It's the intended behavior.  Whether the intention is wrong, I'm not sure.
I believe there was a discussion of the POSIX requirements for this at
some point in the past, and the non-zsh-emulation modes follow POSIX while
(as usual, e.g. shwordsplit) zsh-mode does what it thinks is preferable.

It's possible that ksh also does not follow POSIX and therefore zsh's ksh
emulation shouldn't do so.  Or its possible that ksh does two different
things depending on the form of the function declaration, e.g. whether

	function e { ... }
vs
	e() { ... }

and zsh is only able to emulate one or the other because it does not 
distinguish the two the way ksh does.  (There is no promise made that zsh
will be able to run ksh scripts unmodified; zsh doesn't support namerefs,
among other things.)

> If so, should I file a report @ sourceforge.net?

I keep thinking we should just disable the bug tracker at sourceforge.  I
don't think anyone pays regular attention to it any more.  Bug reports are
usually "filed" by sending them to the zsh-workers mailing list.

Re: ksh Emulation Not Clearing Envariables

[Peter Stephenson]

Bart Schaefer wrote:
> On Sat, 8 May 2004, Chris Jepeway wrote:
> 
> > I'd expect the output to be
> > 
> > 	X=one
> > 
> > Instead, I see
> > 
> > 	X=one
> > 	X=one
> > 
> > Without ksh emulation enabled, I see the expected output.
> > 
> > This is a bug, right?
> 
> It's the intended behavior.  Whether the intention is wrong, I'm not sure.
> I believe there was a discussion of the POSIX requirements for this at
> some point in the past, and the non-zsh-emulation modes follow POSIX while
> (as usual, e.g. shwordsplit) zsh-mode does what it thinks is preferable.

I vaguely remember the argument years ago...

bash and ksh 88 both remove the environment variable, so probably we
ought to do the same.  It would be odd for zsh to insist on niceties
when the shells based more firmly on POSIX don't.

Solaris8 sh doesn't actually bother to set X at all when the command is a
function.  Strange.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: ksh Emulation Not Clearing Envariables

[Chris Jepeway]

>
>> I'd expect the output to be
>>
>> 	X=one
>>
>> Instead, I see
>>
>> 	X=one
>> 	X=one
>>
>> Without ksh emulation enabled, I see the expected output.
>>
>> This is a bug, right?
>
> It's the intended behavior.  Whether the intention is wrong, I'm not 
> sure.
Odd.

POSIX wants the envariable to persist across invocations
of the function "e"?  That seems...counter-intuitive.
I thought the whole point of

	VAR=val cmd

was as a shortcut to

	export VAR=val ; cmd ; unset VAR

nevermind dovetailing with execve()'s env pointer.

Sure, in this case, cmd is a shell function, but...well...so what?
Eeesh.  POSIX.

But, anyways, the command is "emulate ksh" not "emulate posix".
Any chance this behavior could change to follow ksh?  ksh88 as
distributed w/ Solaris-8 is what I'm using for comparison.

>> Me
> Bart

Chris <jepeway@blasted-heath.com>.
(Oh, hey, could folk cc me on replies?  I'm not yet on the list.)

Re: ksh Emulation Not Clearing Envariables

[Chris Jepeway]

> Solaris8 sh doesn't actually bother to set X at all when the command 
> is a
> function.  Strange.
Yeah, it is.  But then, shell functions are from Korn shell, not Bourne 
shell,
if I've got my history right.

> Peter Stephenson <pws@csr.com>                  Software Engineer
Chris <jepeway@blasted-heath.com>.

Re: ksh Emulation Not Clearing Envariables

[Peter Stephenson]

Chris Jepeway wrote:
> POSIX wants the envariable to persist across invocations
> of the function "e"?  That seems...counter-intuitive.
> I thought the whole point of
> 
> 	VAR=val cmd
> 
> was as a shortcut to
> 
> 	export VAR=val ; cmd ; unset VAR
> 
> nevermind dovetailing with execve()'s env pointer.
> 
> Sure, in this case, cmd is a shell function, but...well...so what?
> Eeesh.  POSIX.
> 
> But, anyways, the command is "emulate ksh" not "emulate posix".
> Any chance this behavior could change to follow ksh?  ksh88 as
> distributed w/ Solaris-8 is what I'm using for comparison.

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.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: ksh Emulation Not Clearing Envariables

[Chris Jepeway]

>>> 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.

Re: ksh Emulation Not Clearing Envariables

[Bart Schaefer]

[Hmm, I haven't seen Chet's original message, yet.]

[It's almost time to move this to zsh-workers.]

On Tue, 11 May 2004, Chris Jepeway wrote:

> > 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.

"Variable assignments specified with" refers to this:

> It's outside, put into the environment before the [built-in] is called.

E.g.

	CDPATH=
	CDPATH=/tmp cd foo
	echo $CDPATH

should output "/tmp", because "cd" is a special built-in.  There is no 
other way to interpret "assignments specified with" because an assignment
cannot occur "inside" cd the way it can occur "inside" a function.

> 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."

(1) envariables poked into the environment of a command shall persist
across command invocations when that command is a special-built in.

(2) functions shall have the behavior of special built-ins.

QED.

Again this need not have anything to do with ksh emulation, but it's 
certainly POSIX emulation.

And I think there are other things controlled by the POSIX_BUILTINS 
option (?) so it may not be as easy as turning that off for ksh.

Re: ksh Emulation Not Clearing Envariables

[Chris Jepeway]

>>> 	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 <jepeway@blasted-heath.com>.