From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from math.gatech.edu (euclid.skiles.gatech.edu [130.207.146.50]) by werple.net.au (8.7/8.7.1) with SMTP id DAA15416 for ; Fri, 24 Nov 1995 03:43:19 +1100 (EST) Received: by math.gatech.edu (5.x/SMI-SVR4) id AA29414; Thu, 23 Nov 1995 11:20:20 -0500 Resent-Date: Thu, 23 Nov 1995 11:16:41 -0500 Old-Return-Path: Message-Id: <199511231616.LAA02869@redwood.skiles.gatech.edu> To: zsh-workers@math.gatech.edu Subject: Re: timing builtins etc. In-Reply-To: Your message of "Thu, 23 Nov 1995 11:12:47 +0100." <9511231012.AA14552@sgi.ifh.de> Date: Thu, 23 Nov 1995 11:16:41 -0500 From: Richard Coleman Resent-Message-Id: <"GLqeS.0.TB7.4z9jm"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/638 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > (Thought I'd sent this: it looks like I exited Emacs before MH > finished sending it.) Do you use mh-e? It appears there are a lot of mh/exmh/mh-e users on here (I use both mh and exmh). > I have been working on the bug that builtins and shell functions can't > be timed. I found a neat way of doing it which simply involved adding > the current process to the job list. This even supplied a more > natural way of fixing the previous bug that a builtin run at the end > of the pipeline lost its status to something before. It was all very > swish, and it works fine for builtins. > > Unfortunately it doesn't work for shell functions. The culprit is the > list_pipe code in exec.c, which randomly deletes the job from the > table and it gets used for other purposes later (you can't simply > hijack the new current job). So the code worked where the shell > function was inside a pipe, such as `echo foo | fn', but not on its > own. > > Unfortunately, too, the list_pipe code is horrendously complicated and > completely uncommented and I've never understood any of it. Can > anybody suggest anything? Does anybody know why it randomly deletes > jobs? Isn't there a neater way of fixing the original problem? > > I'm tempted to pretend that the code is already in a pipeline when > `time' is used. I'm not quite sure yet what effect this will have. Peter, could you send me a copy of what you do so far? That way I can keep that in mind when I work on this. I'm also unhappy with the code in execpline and execpline2. I've been planning on cleaning that up, but I wanted to wait until we were at a semi-stable positition (since I'm sure I'll break something). Since beta12 appears fairly stable, I'll try to work on that some. There are a couple of things that I'll been thinking about for the pipeline code. The first is that it is completely undocumented. I'll try to fix that one. The second is how it handles current shell jobs. In execpline2, there is the comment /* if we are doing "foo | bar" where foo is a current * * shell command, do foo in a subshell and do the * * rest of the pipeline in the current shell. */ Does anyone know why this special case was added? Because of this, if you try to do something like jobs | wc -l it doesn't do what people expect. Since `jobs' runs in a subshell, there are no jobs to report, so the above line always returns 0. I checked bash and it returns the correct answer. rc