home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / wizards / 4733 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  4.1 KB
  1. Xref: sparky comp.unix.wizards:4733 comp.unix.shell:4741 comp.unix.misc:4202
  2. Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
  3. Path: sparky!uunet!gumby!wupost!cs.utexas.edu!tamsun.tamu.edu!ski8032
  4. From: ski8032@tamsun.tamu.edu (The Man Behind The Curtain)
  5. Subject: Re: The Problem with UNIX
  6. Message-ID: <1992Nov16.195733.14842@tamsun.tamu.edu>
  7. Organization: Texas A&M University, College Station
  8. References: <1992Nov9.172715.16367@cs.wisc.edu>
  9. Date: Mon, 16 Nov 1992 19:57:33 GMT
  10. Lines: 91
  11.  
  12. Thus spake so@brownie.cs.wisc.edu (Bryan S. So):
  13. >I am doing research on UNIX command line interface problems.
  14. >I am sure everyone has his/her favorite UNIX troubles, would
  15. >you post or email me what's your favorites?  What should have
  16. >been done by UNIX to resolve that problem in general?
  17. > [..]
  18. >To start the discussion, consider the following problems:
  19. >
  20. >    cat a b > b
  21.  
  22. Or tail -10 .fingerees > .fingerees
  23. Clearly what I would like to do is chop out all but the last ten
  24. lines of .fingerees (This file contains a list of whoever has
  25. fingered me.  It is now 
  26.      124 .fingerees  lines long.  Rather cumbersome.)  But
  27. instead I must do 
  28.  
  29. tail -10 .fingerees > result.txt; mv result.txt .fingerees
  30.  
  31. A much less elegant solution.  How can the shell know what is
  32. going on however?  What if cat -> /usr/5bin/echo for instance?
  33.  
  34. So this would be my proposal.  Rather than requiring that the
  35. shell know everything about any possible application it could
  36. run and make it try to figure out all the possible ramifications
  37. of its actions, could we try something like this...
  38.  
  39. The shell sees
  40. tamsun ~> cat a b > b
  41. First, it finds /usr/bin/cat.  Then it looks inside a file called,
  42. let's say .cat.  The file contains a few lines of specifications
  43. in some language know to the shell like this
  44.  
  45. % Cat specifications & limitations
  46. % All files on the cmd line are read-only
  47. % Write permission is not given for the current
  48. % process for these files
  49.  
  50. $* files read-only
  51.  
  52. end
  53.  
  54. The shell makes a list of read only files for the current process
  55. (a b) and then proceeds on, and tries open b.  Since permission
  56. is not there, the operation fails and an error message is returned.
  57. (The error msg could possibly be described in .cat)  Though some
  58. shells will return an error msg already, it destroys your data
  59. anyway.  This could avoid it, or allow the specification to tell
  60. it how to deal with it.
  61.  
  62. For example, ask the user if they wish to concatenate a & b
  63. and store the result in b.  If they answer yes, the shell does...
  64. cat a b > uniq-name; mv uniq-name b
  65. (Being careful about going over quotas, etc.)  And voila!  The
  66. problem was handled with intelligence and grace.  Not to mention
  67. that future programs can inform the shell what actions they are
  68. doing w/o having to rewrite the shell each time to make it guess.
  69.  
  70. /usr/bin/.echo might be empty or not exist, thus telling the shell
  71. that it doesn't have to worry about protecting/overwriting input
  72. files.  (Of course, .echo must be in the real place of the actual
  73. file...)
  74.  
  75. Note that this is just being sketched out in rough detail,
  76. particularly when I say something like 'current process' but
  77. I think it would provide a great level of intelligence and
  78. friendliness to the Un*x shell and would be feasible.  What
  79. do true Un*x advocates think?
  80.  
  81. BTW, the reason why many people are clamoring for a friendlier
  82. Un*x shell is that while Un*x may be expert-friendly, it's lack
  83. of user friendliness will definitely hinder its acceptance in
  84. the larger world.  While some Un*x weenies may scoff at those
  85. who choose other alternatives, doing so only hurts Un*x, for
  86. by expanding and growing it can only improve.  Version numbers
  87. on files, for instance, might be a better way to handle the
  88. above problems for instance.
  89.  
  90. And Un*x is definitely not "user-friendly," at least not to
  91. anyone I've talked to.  Only Un*x advocates and Un*x tutorials
  92. claim such a thing.  I wonder what they are comparing it
  93. to..  CP/M perhaps?  It is clearly time for Un*x to
  94. reach out and COPY /B someone. + ,,
  95.  
  96. >Bryan So
  97.  
  98. -- 
  99. Till next time,                \o/   \o/
  100.                                 V \o/ V     email:pinky@tamu.edu
  101. <>  Sam  Inala  <>                 V
  102.  
  103.