From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6486 invoked from network); 19 Jan 2000 19:36:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 19 Jan 2000 19:36:14 -0000 Received: (qmail 29031 invoked by alias); 19 Jan 2000 19:36:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9378 Received: (qmail 29024 invoked from network); 19 Jan 2000 19:36:08 -0000 To: zsh-workers@sunsite.auc.dk Subject: Re: If someone wants to try... In-reply-to: "Sven Wischnowsky"'s message of "Wed, 19 Jan 2000 16:46:18 +0100." <200001191546.QAA15764@beta.informatik.hu-berlin.de> Date: Wed, 19 Jan 2000 19:38:33 +0000 From: Peter Stephenson Message-Id: Sven Wischnowsky wrote: > Missing initialisation for a tstack field in two places. Yes, now `which _path_files' (which was in effect what was going wrong before) works, which is a pretty good test. However, I can get a core dump with this: fn() { [[ $#ignore -eq 0 && -z $gopt && -n $FIGNORE ]] if [[ "$pre[1]" = \~ ]]; then; fi } which fn (I'm not saying the last bit should necessarily work, although it would be nice if it did nothing, simply that it shouldn't core dump when you look at it.) It's probably related to: % fn() { if true; then; fi; } % which fn fn () { if true then } > And maybe we should try to avoid building values for arrays and hashes > when completing their names (it's autoparamslash if I'm not completely > mistaken). No patch for this yet. Yes, something similar is going on with $mapfile which I noticed before, although maybe this is deeper in the parameter code: it always executes the special function to retrieve the value, even if you're about to assign to it. -- Peter Stephenson