Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!AUREL.CNS.CALTECH.EDU!bfox
From: bfox@AUREL.CNS.CALTECH.EDU (Brian Fox)
Newsgroups: gnu.bash.bug
Subject: background jobs in 1.04
Message-ID: <8911231630.AA08016@aurel.cns.caltech.edu.>
Date: 23 Nov 89 16:30:27 GMT
References: <13611@reed.UUCP>
Sender: daemon@tut.cis.ohio-state.edu
Reply-To: bfox@aurel.cns.caltech.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 26


   Date: 23 Nov 89 00:52:39 GMT
   From: ctrsol!emory!ogccse!reed!trost@gem.mps.ohio-state.edu  (Bill Trost)
   References: <278200004@sts>
   Sender: bug-bash-request@prep.ai.mit.edu

   Roy Bixler <roy@sts.com> writes:
   "... I don't see any reason why a builtin command
   shouldn't do this.  The C shell will even notify you of job completion
   after you've typed a carriage return.

   "Also, the C shell has a variable called 'notify', which when set, will
   asynchronously notify you that your background job is finished.  How
   about if Bash had this too?"

   Seconded.  Waiting for jobs to complete has been rather bizarre in
   bash, especially since the most natural way to see if a job is done is
   by typing "jobs", and the command doesn't give correct information.
   It would seem that the best place to see if jobs have been completed
   would be right before the potential execution of the PROMPT_COMMAND.
   --
   --

notify=

Brian