From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5073 invoked from network); 19 Nov 1998 15:29:04 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 19 Nov 1998 15:29:04 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id KAA16701; Thu, 19 Nov 1998 10:25:28 -0500 (EST) Resent-Date: Thu, 19 Nov 1998 10:25:28 -0500 (EST) Message-Id: <9811191508.AA09366@ibmth.df.unipi.it> To: zsh-workers@math.gatech.edu (Zsh hackers list) Subject: unsetting array elements Date: Thu, 19 Nov 1998 16:08:45 +0100 From: Peter Stephenson Resent-Message-ID: <"qGNu03.0.u44.dX3Ls"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4673 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu I've just been looking into the unset problem, and it looks like ksh 88 (this one's called Version 11/16/88d SBCS) is doing something a little bit dodgy. > set -A var foo bar > unset var[0] # works this time > echo ${var[*]} bar > set -A var foo bar > touch var0 > unset var[0] # this time var[0] -> var0 > echo ${var[*]} foo bar So in that version unset behaved as a normal command, just relying on the fact that the thing was left alone if it didn't match a file. Unsetting elements doesn't work at all yet in zsh. It's harder to implement because of the nomatch and nullglob behaviours. Of course, you could get it to work in quotes and say so in the manual. Or you could turn off globbing for unset, which could be implemented in the same way that typeset knows when to expand ~'s after an `=' --- probably workable since you'd have to be a complete weirdo to rely on globbing in this case. By the way, ksh also ignores unset parts of arrays completely, even with "${var[@]}". Zsh would emit extra empty strings for the unset part, and this requires some major surgery to change since a null byte marks the end of the array. In associative arrays you can remove the element completely and it's not a problem. I'd thought of making a bolder project both to make unset special and to have typeset etc. get variable-type arguments instead of just strings, which would make things like `local var=(foo bar)' work; the current behaviour tends to surprise people. But that would require spotting the command very early on during parsing which would have all sorts of side effects of two types: first, quoting bits of the command name would turn this off; second, it would have to decide at parse time whether there was a function instead, or whether the command was disabled, and things like 'builtin typeset' would have to be special-cased in the parser. Then you'd probably have to keep the existing typeset code for cases where the command was called without the special parsing activated. So it looks rather unpleasant. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy