From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16313 invoked from network); 24 Oct 1999 21:13:37 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Oct 1999 21:13:37 -0000 Received: (qmail 21435 invoked by alias); 24 Oct 1999 21:13:32 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8395 Received: (qmail 21428 invoked from network); 24 Oct 1999 21:13:31 -0000 Subject: Re: Parameter module, $functions, and autoloading In-Reply-To: <991024055629.ZM1635@candle.brasslantern.com> from Bart Schaefer at "Oct 24, 1999 5:56:28 am" To: schaefer@candle.brasslantern.com (Bart Schaefer) Date: Sun, 24 Oct 1999 22:13:30 +0100 (BST) Cc: zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL48 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Bart Schaefer wrote: >An interesting solution to both problems occurred to me today: Create a >builtin "undefined" that works like the alias above. That builtin could >have access to the function name and argv independent of FUNCTION_ARGZERO, >and would simply perform the autoload and execute. It could even take an >option -U having the same meaning as "autoload -U". Would be nice. Autoloaded functions are already internally executed in a manner pretty close to this; it's tempting to change autoload to just define the function with a body consisting of a call to this builtin. The only issue I see is, unfortunately, a biggie. What happens if you have a function defined like this, then the user defines "undefined" as a shell function (taking precedence over the builtin) and then tries to execute the supposedly-autoloaded function? Also consider disabling the builtin. You'd need some special syntax, rather than just a command name, to avoid this potential clash. If you do go with a special syntax, I suggest that the syntax allow an arbitrary command name, rather than just handling this one case of autoloaded functions. There may be other things in the future for which we want non-overridable builtin command syntax. >A more complicated solution involves a minor parsing rewrite: Create a >new reserved word "undefined". We can't define any new reserved words and retain sh/ksh compatibility. That's even worse than a builtin. Oh, I suggest that the name "autoloaded" is clearer than "undefined", if we do do any of this. I never liked that bit of the `functions` format: if a function is undefined, surely it doesn't exist at all, and shouldn't be output. -zefram