Zsh Mailing List Archive
Messages sorted by:
Re: env variables
- X-seq: zsh-workers 3923
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: env variables
- Date: Mon, 4 May 1998 03:41:03 -0700
- In-reply-to: <slrn6kqe41.a1r.mason@xxxxxxxxxxxxxxxxxxxxx>
- References: <slrn6kk9m5.dqb.mason@xxxxxxxxxxxxxxxxxxxxx> <199805012044.NAA22048@xxxxxxxxxxxx> <slrn6kqe41.a1r.mason@xxxxxxxxxxxxxxxxxxxxx>
On May 4, 3:39am, Geoff Wing wrote:
} Subject: Re: env variables
} Nik Gervae <Nik@xxxxxxx> typed:
} :> Arrays aren't exported, because there's no standard or de facto
} :> method of exporting arrays, so nothing would understands them
} :Hmm. That sounds slightly fishy in that csh happily exports array
} :variables, but then csh is bogus in so many ways....
} Not as arrays. In fact, I can't see it doing it at all.
The problem is not really with exporting arrays ... the problem is with
exporting a variable whose name happens to be the same as one of zsh's
special array variables.
In the case in question, some program wants a variable named "cdpath" to
be in the environment. It probably expects that to be a colon-separated
string, but it doesn't really matter what it expects, because zsh won't
put a variable named "cdpath" in the environment. It actively removes
such a variable from the environment if it happens to be there when the
shell starts up.
This is one reason I've always preferred csh's model of keeping local
and environment variables in completely separate namespaces. (The icky
bit about the csh model is that you still refer to both with $xxx, so
you can't tell what namespace you're referencing.) (No, zsh should not
The only workaround is to export the variable for a single command only,
In older versions of zsh, that would have clobbered both cdpath and CDPATH
for the current shell, but fortunately that's fixed in current releases
so you can use it safely.
Hmm; hey, Peter, another FAQ entry?
Bart Schaefer Brass Lantern Enterprises
Messages sorted by: