home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / internal / 1787 < prev    next >
Encoding:
Text File  |  1992-09-09  |  1.8 KB  |  42 lines
  1. Newsgroups: comp.unix.internals
  2. Path: sparky!uunet!stanford.edu!leland.Stanford.EDU!dayton.Stanford.EDU!lma
  3. From: lma@dayton.Stanford.EDU (Larry Augustin)
  4. Subject: Re: How can a Unix process put itself in background?
  5. Message-ID: <lma.716092591@dayton.Stanford.EDU>
  6. Sender: news@leland.Stanford.EDU (Mr News)
  7. Organization: DSO, Stanford University
  8. References: <lma.716056953@dayton.Stanford.EDU>
  9. Date: 10 Sep 92 02:36:31 GMT
  10. Lines: 30
  11.  
  12. lma@dayton.Stanford.EDU (Larry Augustin) writes:
  13.  
  14. >Someone stopped by my office with this question yesterday.
  15.  
  16. >A user invokes a program at the shell, and interacts with the program
  17. >for a short time.  Eventually the user selects some "quit" option of
  18. >the program.  Before the program really quits, it wants to go off and
  19. >spend a minute or two checking some database files on disk.  Is there
  20. >any way for the program to return control to the user's shell while it
  21. >does the background stuff?  In effect, the program wants to "detach"
  22. >itself from stdin/stdout, return control to the shell, and continue in
  23. >background for a while before exiting.
  24.  
  25. >The only solutions we could come up with were based on forking a child
  26. >to do the background part.  is this the only way to do it?  Is there a
  27. >solution that does not need a fork?
  28.  
  29. I know about job control!  I'm NOT asking how to use job control!  I'm
  30. talking about writing a C program that places ITSELF in background.
  31. I'm not talking about the user typing ^Z.
  32.  
  33. Please, no more messages telling me how to use ^Z!
  34.  
  35. The consensus seems to be that it can't be done (without forking), as
  36. whatever shell exec'd the program will be stuck in a wait(), and could
  37. only continue upon death of the child (or some interaction by the
  38. user).  There would have to be some other convention for the running
  39. program to tell the shell to continue.
  40.  
  41. Larry
  42.