From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16848 invoked from network); 24 Oct 1999 22:52:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Oct 1999 22:52:14 -0000 Received: (qmail 27581 invoked by alias); 24 Oct 1999 22:52:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8398 Received: (qmail 27568 invoked from network); 24 Oct 1999 22:52:08 -0000 From: "Bart Schaefer" Message-Id: <991024225159.ZM13245@candle.brasslantern.com> Date: Sun, 24 Oct 1999 22:51:58 +0000 In-Reply-To: Comments: In reply to Zefram "Re: Parameter module, $functions, and autoloading" (Oct 24, 10:13pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Zefram Subject: Re: Parameter module, $functions, and autoloading Cc: zsh-workers@sunsite.auc.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 24, 10:13pm, Zefram wrote: } Subject: Re: Parameter module, $functions, and autoloading } } 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. Yes. } 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. Ah, yes; but we already have just such a syntax ... } Oh, I suggest that the name "autoloaded" is clearer than "undefined", } if we do do any of this. How about this: Rather than "autoloaded" or "undefined" we just make it an option to "autoload" itself. -X, perhaps, for "eXecute"? And another one, perhaps -I for "Immediate" or -e for "evaluate", that loads in the definition without calling it? And then "autoload -U foo" defines foo as foo() { builtin autoload -UX } (Or even foo() { builtin autoload -UX foo "$@" } if that seems more appropriate than having "autoload -X" with no args get the surrounding context magically; but I lean to the former, to avoid any ambguity about what is done with "$@" in that latter example.) If someone does "disable builtin" they're going to be in deep doodoo in any event. And it seems reasonable to expect that if they're creating functions with "autoload" in the first place, then it won't be disabled when the functions are called. } 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. I was afraid it was that way to dupicate ksh's output, or something. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com