home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / misc / 3632 < prev    next >
Encoding:
Text File  |  1992-09-10  |  2.7 KB  |  74 lines
  1. Newsgroups: comp.unix.misc
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!menudo.uh.edu!sugar!ficc!peter
  3. From: peter@ferranti.com (peter da silva)
  4. Subject: Re: Giles' (Manual) Mania (getting longuish)
  5. Message-ID: <id.I34T.F16@ferranti.com>
  6. Organization: Xenix Support, FICC
  7. References: <1992Sep8.183712.18867@newshost.lanl.gov> <7269@charon.cwi.nl> <1992Sep9.192946.27394@newshost.lanl.gov>
  8. Date: Thu, 10 Sep 1992 17:15:28 GMT
  9. Lines: 63
  10.  
  11. In article <1992Sep9.192946.27394@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
  12. > Yes, you're quite right, that's why UNIX doesn't have asynchronous
  13. > I/O.
  14.  
  15. This is (and I've commented on it before) the only real problem with the
  16. UNIX API. And it would be *so* easy to fix, in a completely compatible way,
  17. by introducing the concept of file tokens.
  18.  
  19. > Can you explain why the UNIX environment has two different pattern
  20. > matching syntaxes (wildcards and regular expressions)
  21.  
  22. Because regular expressions are inconvenient for interactive use, and
  23. wildcards are inadequate for many purposes.
  24.  
  25. > and why the 
  26. > different tools which need to do pattern matching are rather
  27. > idiosyncratic about which they use?
  28.  
  29. Apart from the shell, what uses wildcards?
  30.  
  31. > Can you explain why, although
  32. > different, they use the *same* characters as meta-symbols (so each
  33. > has to be quoted to get through the other)?
  34.  
  35. Historical dreg. There are some problems with the standard shells. This
  36. is not an inherent UNIX problem
  37.  
  38. > Can you explain why there are two different tools to inquire the
  39. > same database (the file directories): ls and find?
  40.  
  41. Oh, there are more than just those two. You forgot wildcards.
  42.  
  43. > Can you explain why line-at-a-time text filters *exist* in UNIX (when
  44. > the brag is that UNIX imposes no structure on files)?
  45.  
  46. UNIX imposes no structure on files. Applications and tools do. These tools
  47. exist because they're convenient.
  48.  
  49. > Can you explain
  50. > why such line-at-a-time filters have *different* line and files size
  51. > limits?
  52.  
  53. They shouldn't have any. Fixing this should have been a basic requirement
  54. for commercial release of UNIX. A really good commercial quality UNIX has
  55. not yet been built.
  56.  
  57. > Can you explain why *no one* seems satisfied with UNIX text editors
  58.  
  59. I am.
  60.  
  61. > *THIS* would be consistent, but the UNIX
  62. > environment won't even *let* me do it.  Why?  They *CLAIM* it's for
  63. > consistency!!
  64.  
  65. No, it's for convenience. To make the normal case work better.
  66.  
  67. The fix is to use a network file system instead of the r-suite. Berkeley
  68. networking is such a kludge.
  69. -- 
  70. Peter da Silva                                               `-_-'
  71. Ferranti Intl. Ctls. Corp.                                    'U` 
  72. Sugar Land, TX  77487-5012
  73. +1 713 274 5180                                   Har du kramat din varg idag?
  74.