From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22976 invoked from network); 5 Jun 1997 06:34:46 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 5 Jun 1997 06:34:46 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id CAA15639; Thu, 5 Jun 1997 02:15:42 -0400 (EDT) Resent-Date: Thu, 5 Jun 1997 02:15:42 -0400 (EDT) From: Zoltan Hidvegi Message-Id: <199706050618.CAA06697@hzoli.home> Subject: Re: exporting arrays In-Reply-To: <3395B9DA.58C1C527@rrz.uni-hamburg.de> from Bernd Eggink at "Jun 4, 97 08:54:18 pm" To: eggink@rrz.uni-hamburg.de (Bernd Eggink) Date: Thu, 5 Jun 1997 02:18:40 -0400 (EDT) Cc: zsh-workers@math.gatech.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"vCJSf2.0.Iq3.8cbbp"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3206 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > "ar" shows up in the list, but in the following 'zsh'-invocation it is > unset. Is this intentional? I didn't find any restrictions mentioned in > the manual. The restriction is in Unix. The contents of an environment variable is always a plain null-terminated string on Unix. It is possible to hack something as a workaround, but there is no prefect solution as far as I know. Neither bash not ksh exports arrays. More precisely ksh93 does export arrays but only the first array element gets into the enviromnet (which is consistent since without subscritps a ksh array behaves like a variable with the first array element as its value). Exported functions has similar problems (just try foo='() {' bash to see what I meen). Probably that's why ksh93 does not have exported functions and POSIX does not require it. The foo()=... encoding to put functions into the environment seems to be more reasonable and does not have the problem mentioned above. It was even included in some early POSIX drafts. I wonder why doesn't bash use that method instead of this ambiguous foo='() { ...' encoding. Zoltan