Re: PATCH: local exports

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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