From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Peter Stephenson <pws@cambridgesiliconradio.com>,
zsh-workers@sunsite.auc.dk (Zsh hackers list)
Subject: Re: PATCH: local exports
Date: Thu, 13 Apr 2000 15:42:36 +0000 [thread overview]
Message-ID: <1000413154237.ZM16996@candle.brasslantern.com> (raw)
In-Reply-To: <0FSY00C9K66ILS@la-la.cambridgesiliconradio.com>
In-Reply-To: <0FSY00H1OKQ2PE@la-la.cambridgesiliconradio.com>
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
next prev parent reply other threads:[~2000-04-13 15:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-04-12 6:14 List of unresolved issues Bart Schaefer
2000-04-12 15:56 ` Andrej Borsenkow
2000-04-12 20:55 ` Peter Stephenson
2000-04-13 0:26 ` Bart Schaefer
2000-04-13 8:56 ` Peter Stephenson
2000-04-13 14:10 ` PATCH: local exports Peter Stephenson
2000-04-13 15:42 ` Bart Schaefer [this message]
2000-04-13 17:54 ` PATCH: " Peter Stephenson
2000-05-01 5:21 ` List of unresolved issues (update) Bart Schaefer
2000-05-01 9:09 ` Adam Spiers
2000-05-02 9:50 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1000413154237.ZM16996@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=pws@cambridgesiliconradio.com \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).