From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27903 invoked from network); 26 Mar 1998 11:15:47 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 26 Mar 1998 11:15:47 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id GAA06823; Thu, 26 Mar 1998 06:08:08 -0500 (EST) Resent-Date: Thu, 26 Mar 1998 06:08:08 -0500 (EST) Date: Thu, 26 Mar 1998 11:07:25 GMT From: Andrew Main Message-Id: <199803261107.LAA32378@diamond.tao.co.uk> To: gdfast@srv1dilurb.er.usgs.gov Cc: zsh-workers@math.gatech.edu Subject: Re: default command function Resent-Message-ID: <"J-NIm1.0.Yg1.NSZ6r"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3820 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Gregory D. Fast wrote: >Perl has an amusing feature whereby the sub named AUTOLOAD, if defined >in the current package, gets called in place of a "subroutine not >found" error. The idea is that AUTOLOAD reads the sub definition from >somewhere, breathes life into it, and then calls it. It basically allows >you to create default behavior for undefined subroutines. > >I like it a lot, and wished that I could somehow trick zsh into acting >likewise, so I modified exec.c so that if a command is not found, it execs >(assuming it's defined) _default_cmd(), with the (failed) command line >as its args. Unfortunately, by the time the command failure is detected, the shell has already forked, so the most useful application of this sort of feature -- defining a shell function -- is not possible. In fact, very little of any utility is possible. Therefore this patch is not going into the next zefram release. I'd like to have some way for the main shell process to detect reliably whether external command execution failed, so that this could be done properly. Perhaps a close-on-exec pipe, with an error number being sent down the pipe in case of error? This would open up other possibilities: the command search mechanism could be put completely under user control, with the possibility of user- (or module-) defined forms of command execution. Perhaps the command search order (builtin, function, external command, ...) could go into a shell parameter, making `builtin' and `command' just special cases of this more general facility. (I think this sort of feature was first suggested to me by Richard, and I have recently implemented it, in a very general form, in a shell I wrote for a non-Unix OS.) I envision having a new hash table, for command executors; these would be defined the way builtin commands are (some in the base executable, with modules being able to add to the table). When simple commands are executed then the command executors named by an array parameter would be tried in sequence. Really wacky idea: a module could provide a builtin that provides the capability to invent new command executors based on a shell function, which gets run with the relevant parameter modified. -zefram