Re: PATCH: Re: PATCH: local exports

Re: PATCH: Re: PATCH: local exports

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> Oddly, this wasn't actually my fault; it came from the import of special
> parameters at startup.  The code set the variable, then tried to replace
> the value in the environment with the value generated internlly, for
> consistency.  Unfortunately it was trying to replace it into the old
> environment, which failed.  This returned null, which was set to the env
> element of the parameter struct.

Hm... importing special parameters... could this have something to do
with Bart's FPATH problem? But I debugged through the FPATH-importing
when trying to reproduce his problem and that seemed to work fine...


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: local exports

[Bart Schaefer]

On Apr 13,  9:56am, Peter Stephenson wrote:
} Subject: Re: List of unresolved issues
}
} > There's already been a patch that makes `typeset -x' == `typeset -gx'.
} 
} Oh, that passed me by.  In that case zsh definitely isn't consistent, either.

The reason for that patch is that having `typeset -x' require `-g' when
used inside a shell function breaks compatibility with 3.0 and earlier
zsh.  I could be argued out of it (or simply overruled, I supposed) but
it caused some of my autoloaded functions to fail (e.g., a cvs wrapper
that I use to force CVSROOT=$(<CVS/Root) into the environment, which is
intended to have it remain in the environment after the function exits).

On Apr 13,  3:10pm, Peter Stephenson wrote:
} Subject: PATCH: local exports
}
} It seems to be agreed that not having local parameters exportable is a
} bug.  This is an attempt to fix it.

It's only a bug in ksh emulation.  It's not a bug in bare zsh.  Exporting
locals is a possibly-useful feature, but no more.

} I'm sure this needs more testing.  I removed some special cases that
} prevented exports of locals in various places in the code, but it's
} possible there are some others hanging around.

The following seems to be a pretty effective test:

  unenv() {
    local x
    x=($(typeset +x))
    local $x
    unset $x
    /usr/bin/printenv	# $path is (correctly?) nuked by unset PATH
  }

The output on my system differs if I run this function twice.  The first
time it is:

  TERM=xterm
  HOME=/home/schaefer
  _=/usr/bin/printenv
  COLUMNS=80
  LINES=24

and the second time:

  _=/usr/bin/printenv

which is what I would have expected both times.

Futher, if I do this:

  printenv | sort > /tmp/before
  unenv
  printenv | sort > /tmp/after
  diff /tmp/before /tmp/after

I get no differences in the before and after output, which is exactly as
it should be.
 
} I made `typeset +g -x' respect the explicit `+g', and I allowed `local' to
} take `-x' without forcing on `-g' --- I take it this is uncontroversial.

I think this is fine.

} This was necessary to get around the -g-with--x kludge.  Ksh 88 doesn't
} have that and its `typeset -x' behaves more or less like `typeset +g -x'.

This is why I keep talking about ksh emulation.  I want to be able to
keep exporting things from functions with `typeset -x' the way I have
for the entire time I've been using zsh, but it causes problems when
running scripts written for ksh.

} 1 - We don't actually need the -g-kludge for typeset -x any more; it
} doesn't correspond to ksh 88 (see above), wasn't present or documented in
} zsh until one of the current development series, and isn't consistent with
} the behaviour of the remaining flags.

I don't know what you mean about "wasn't present or documented ...".  It
has been documented all through the 2.xx and 3.x series that `export' is
the same as `typeset -x'.  Changing the behavior of `typeset -x' to imply
localness is a serious incompatibility.

} 2 - `export' in any case behaves like it does in ksh, though in zsh's case
} that means the effect of `typeset -xg', as currently documented.  The zsh
} behaviour was always as now, I believe.  The ksh 88 behaviour makes
} `export' and `typeset -x' behave differently, too, but it's undocumented.

I agree with all those statements.

} 3 - In fact, none of this interaction between exportedness and globalness
} seems to be documented in the ksh 88 manual page.

However, we should be using the ksh93 manual and/or the new ksh book, not
the ksh88 manual.  There are links to current doc on www.kornshell.com.

} 4 - Therefore it's hard to see the use of an option or different emulation
} settings, but it's possible I've missed some other issue.  We're agreed the
} old behaviour was broken, so we don't want to emulate that.

Apparently we're not agreed that the old behavior was broken, for some
definition of "the old behavior."

} 4 - Consequently I think we can remove the -g => -xg kludge in either case.
} But I didn't quite follow why it was there.  If it was simply a workaround
} for the -x being ignored otherwise, then maybe we can simply get rid of it
} and put an end to the matter.

It's not just that the -x was ignored, it's that its meaning changed in a
way not compatible with older zsh.

With the sole exception of the ksh emulation mode question, the behavior
after 10728 is precisely what I intended to be suggesting all along.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

PATCH: Re: PATCH: local exports

[Peter Stephenson]

Bart Schaefer wrote:
> The following seems to be a pretty effective test:
> 
>   unenv() {
>     local x
>     x=($(typeset +x))
>     local $x
>     unset $x
>     /usr/bin/printenv	# $path is (correctly?) nuked by unset PATH
>   }
> 
> The output on my system differs if I run this function twice.  The first
> time it is:
> 
>   TERM=xterm
>   HOME=/home/schaefer
>   _=/usr/bin/printenv
>   COLUMNS=80
>   LINES=24

Oddly, this wasn't actually my fault; it came from the import of special
parameters at startup.  The code set the variable, then tried to replace
the value in the environment with the value generated internlly, for
consistency.  Unfortunately it was trying to replace it into the old
environment, which failed.  This returned null, which was set to the env
element of the parameter struct.  Hence when the new code looked for this
to see if the value was in the environment already it failed, so never
deleted it.  (It was doing this on the `local', not the unset, since the
local parameter wasn't being exported.)  This usually didn't show up
because the values in the environment were OK anyway, as in this case, so
the fact that they didn't get replaced didn't matter.

> } This was necessary to get around the -g-with--x kludge.  Ksh 88 doesn't
> } have that and its `typeset -x' behaves more or less like `typeset +g -x'.
> 
> This is why I keep talking about ksh emulation.  I want to be able to
> keep exporting things from functions with `typeset -x' the way I have
> for the entire time I've been using zsh, but it causes problems when
> running scripts written for ksh.

OK, so it's a ksh compatibility vs. old zsh compatibility issue.  The
problem with using an option is that in this case the latter is the kludge,
but needs to be enabled by default.  There isn't a good way round that.
If somebody wants to write an option they can.  It could be called e.g.
GLOBAL_EXPORT and be on by default; at least that tells you that something's
up.

Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.4
diff -u -r1.4 params.c
--- Src/params.c	2000/04/13 14:22:47	1.4
+++ Src/params.c	2000/04/13 17:51:26
@@ -454,6 +454,7 @@
 {
     Param ip, pm;
     char **new_environ, **envp, **envp2, **sigptr, **t;
+    char **old_environ = environ;
     char buf[50], *str, *iname;
     int num_env, oae = opts[ALLEXPORT];
 #ifdef HAVE_UNAME
@@ -516,9 +517,12 @@
 		    pm->flags |= PM_EXPORTED;
 		    pm->env = *envp++ = ztrdup(*envp2);
 		    *envp = NULL;
-		    if (pm->flags & PM_SPECIAL)
+		    if (pm->flags & PM_SPECIAL) {
+			environ = new_environ;
 			pm->env = replenv(pm->env, getsparam(pm->nam),
 					  pm->flags);
+			environ = old_environ;
+		    }
 		}
 	    }
 	    *str = '=';

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070