zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: "typeset -x" vs. "export" in 3.1.6
Date: Sat, 23 Oct 1999 17:43:11 +0000	[thread overview]
Message-ID: <991023174311.ZM22277@candle.brasslantern.com> (raw)
In-Reply-To: <991023083509.ZM21037@candle.brasslantern.com>

On Oct 23,  8:35am, Bart Schaefer wrote:
} Subject: "typeset -x" vs. "export" in 3.1.6
}
} Consider the following two functions:
} 
} putenv() { typeset -x $1=$2 }
} setenv() { export $1=$2 }
} 
} Is it really intentional that they don't have the same behavior?

I'm coming to the conclusion that this just can't be right.

There doesn't seem to have ever been doc written for "typeset -g".  The
ChangeLog says "doesn't locallize" and my own commitlog says "marks
non-local, which is not the same as global".  Before, "typeset -x" meant
"marks global and puts in the environment, iff not marked local" which
seems to have mutated into "puts in the environment, iff marked global".
This has the effect of rendering -x a no-op anywhere except at the top
level, which I'm pretty sure is incompatible with ksh.

(In bash, "typeset -x" in a function puts the symbol into the environment
but then removes it from the environment again when the function exits;
"export" puts it in the environment and does not remove it again, but it
gets removed when the surrounding context exits if it was local to that
outer context.  Can someone who has a real ksh available please confirm
what the precise ksh behavior is?  Does it differ in 88/93?)

(Note that in 3.1.6, neither "typeset -x" nor "export" puts a local into
the environment under any circumstances.  The difference is only in what
circumstances cause a parameter to be considered a local.)

Achiving compatibility with past versions of zsh (modulo the fix that in
3.0.x "typeset -x FOO=bar" does not assign bar to FOO when FOO is already
a local, although it both assigns and exports if FOO was not previously
declared at all) appears to be as simple as having -x imply -g, and that
would be my preferred solution to all this.  However, I'm not averse to
having zsh do the right thing in an emulation mode.  I'm just pretty sure
it's currently doing the wrong thing in both cases.

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


  reply	other threads:[~1999-10-23 17:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-10-23  8:35 Bart Schaefer
1999-10-23 17:43 ` Bart Schaefer [this message]
1999-10-24 12:25   ` Alexandre Duret-Lutz
1999-10-24 16:09     ` Bart Schaefer

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=991023174311.ZM22277@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.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).