home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / shell / 5182 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  1.4 KB
  1. Path: sparky!uunet!pacsoft!mike
  2. From: mike@pacsoft.com (Mike Stefanik)
  3. Newsgroups: comp.unix.shell
  4. Subject: Re: Handling of '&' by shell
  5. Message-ID: <1479@pacsoft.com>
  6. Date: 29 Dec 92 18:02:42 GMT
  7. References: <1992Dec28.162641.11402@pt.com>
  8. Organization: Pacific Software Group, Riverside, CA
  9. Lines: 24
  10.  
  11. In article <1992Dec28.162641.11402@pt.com> mliu@pt.com (Fred Liu) writes:
  12. >I am just wondering why the shell creates a background process first if
  13. >the '&' is at the end of a command line.  It would be nice to have the
  14. >shell check the command first and then fire up the process. [...]
  15.  
  16. What happens when you're dealing with something more complex than a
  17. single command and it's arguments.  For example:
  18.  
  19.     $ ( while read line; do echo $line; done < file ) | wc -l &
  20.  
  21. Now certainly, the shell could go through all sorts of gyrations to make
  22. sure that the `while' loop is correctly formed and that the `wc' program
  23. actually exists.  Consider if there was more than an `echo' inside the
  24. above loop -- for example, what if there was another nested loop similar
  25. to the one above?
  26.  
  27. What happens is that you have made a relatively simple function in the
  28. shell (ie: forking in the background) an order of magnitude more complex,
  29. for no better reason than aesthetics.  IMHO, it is far better to fork and
  30. let the child shell do it's own complaining.
  31.  
  32. -- 
  33. Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike  (909) 681-2623
  34. Pacific Software Group, Riverside, CA
  35.