Re: timing builtins etc.

[Richard Coleman <coleman@xxxxxxxxxxxxxxx>]

> (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