home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / wizards / 4660 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  2.3 KB
  1. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!rdsunx!barnett
  2. From: barnett@grymoire.crd.ge.com (Bruce Barnett)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: The Problem with UNIX
  5. Message-ID: <BARNETT.92Nov13103027@grymoire.crd.ge.com>
  6. Date: 13 Nov 92 15:30:27 GMT
  7. References: <96927@netnews.upenn.edu> <1992Nov11.210729.11676@cs.wisc.edu>
  8.     <BARNETT.92Nov12092045@grymoire.crd.ge.com>
  9.     <1992Nov12.231845.14014@cs.wisc.edu>
  10. Sender: usenet@crd.ge.com (Required for NNTP)
  11. Reply-To: barnett@crdgw1.ge.com
  12. Organization: GE Corp. R & D, Schenectady, NY
  13. Lines: 42
  14. In-Reply-To: so@brownie.cs.wisc.edu's message of Thu, 12 Nov 1992 23:18:45 GMT
  15. Nntp-Posting-Host: grymoire.crd.ge.com
  16.  
  17. In article <1992Nov12.231845.14014@cs.wisc.edu> so@brownie.cs.wisc.edu (Bryan S. So) writes:
  18. >   I propose a real solution to this problem.  Change the internal
  19. >   policy of UNIX, so that when any file is used as both input and
  20. >   output, like
  21.  
  22. >       cat a b > a
  23. >   or     cat a b > b
  24.  
  25. >UNIX should read and buffer all input before opening the output
  26. >with "w".
  27.  
  28. Maybe. Perhaps the command was a typo, and the user didn't want
  29. to change "b". Perhaps UNIX should use version numbers, like VMS. That
  30. also solves both problems. Maybe UNIX should have an "undo" facility
  31. for all file operations. Maybe cat should be able to read "b" while
  32. it's getting larger (i.e. during the shell command). What about
  33.  
  34.     tail -f b > b
  35.  
  36. Go back to "cat a b >b". Given three different responses:
  37.  
  38.     1. deleting forever the contents of b
  39.     2. giving the user an error message
  40.     3. prepending a to b
  41.  
  42. I argue that #2 is the best choice.
  43.  
  44. Number 1 is bad. Number 2 is safe. Number 3 may or may not be what the
  45. user wanted to do. Given that it is not clear what the user expects
  46. "cat a b >b" to do, I believe a better answer is to simply tell the
  47. user that this might be an error on their part. Anyone who understands
  48. the implications of "cat a b >b" ought to be able to understand how to
  49. get around it. The only time it is a REAL problem is when the size of
  50. files a + b are greater than the amount of free disk space. At this
  51. time, the user should be VERY CAREFUL about the implications of the
  52. operation.
  53.  
  54. Suppose the disk fills up while the new "b" is being created. What
  55. happens afterwards? Is the new "b" deleted? Or the old one?
  56.  
  57. --
  58. Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
  59.