From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12936 invoked from network); 5 Dec 1999 18:06:37 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Dec 1999 18:06:37 -0000 Received: (qmail 407 invoked by alias); 5 Dec 1999 18:06:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8900 Received: (qmail 400 invoked from network); 5 Dec 1999 18:06:26 -0000 To: zsh-workers@sunsite.auc.dk Subject: Re: Bug with parameter module In-reply-to: "Zefram"'s message of "Sun, 05 Dec 1999 12:48:05 GMT." Date: Sun, 05 Dec 1999 18:07:04 +0000 From: Peter Stephenson Message-Id: Zefram wrote: > Peter Stephenson wrote: > >The shell hangs. It seems that executing fn uses some wrapper associated > >with the parameter module which then won't unload. > > Just ignore errors; *attempt* to unload > each module, but leave it if it doesn't unload. That sounds reasonable. I think the reason we need at least to attempt to unload modules is that in general we don't know what code that can trigger; it could in principle be something required for the shell to exit cleanly. But I don't know if that's true (or ever will be true) in practice. This case is something of a counterexample to that attitude. I found another problem while attempting to work around this. zsh -c 'zmodload parameter; zmodload -u parameter fn() { zmodload parameter; zmodload; }; fn' Only the pseudo-module `zsh' shows up; parameter isn't there in the function. If you take away the code on the first line, it is. This stuff makes scripts using the parameter module rather icky at the moment, and as I'm planning on using $options to keep track of options in the test system, it's a bit of a drag. -- Peter Stephenson