zsh-workers
 help / color / mirror / code / Atom feed
From: wischnow@hp832.informatik.hu-berlin.de
To: zsh-workers@math.gatech.edu
Subject: Re:  timing builtins etc.
Date: Fri, 24 Nov 1995 08:24:11 +0100	[thread overview]
Message-ID: <9511240724.AA03273@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Thu, 23 Nov 1995 11:12:47 +0100


Peter Stephenson wrote:

> 
> (Thought I'd sent this:  it looks like I exited Emacs before MH
> finished sending it.)
> 
> 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?
> 

Well, I should be able to say something about, but it's a while back
since I wrote it (one thing drives another thing out, you know...).

I only remember that after most of the stuff I wrote there worked
someone came up with an example of some compicated pipe that suddenly
stopped working. That made me add the deletepipejob() thing and the
first deletejob() in execpline(), but I don't remember the exact
problem.

I think it is clear that the whole exec.c/jobs.c stuff should be
rewritten (not doing so was the real mistake I made), but who will do
that (certainly not me ;-).

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



Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~1995-11-24  7:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-11-24  7:24 wischnow [this message]
  -- strict thread matches above, loose matches on Subject: below --
1995-11-23 10:12 Peter Stephenson
1995-11-23 16:16 ` Richard Coleman
1995-11-23 19:11   ` Barton E. Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9511240724.AA03273@beta.informatik.hu-berlin.de \
    --to=wischnow@hp832.informatik.hu-berlin.de \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).