home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / wizards / 4656 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  3.4 KB

  1. Xref: sparky comp.unix.wizards:4656 comp.unix.shell:4676 comp.unix.misc:4144
  2. Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
  3. Path: sparky!uunet!pipex!warwick!sunserver1.aston.ac.uk!uhura!evansmp
  4. From: evansmp@uhura.aston.ac.uk (Mark Evans)
  5. Subject: Re: The Problem with UNIX
  6. Message-ID: <1992Nov13.104731.29328@aston.ac.uk>
  7. Sender: usenet@aston.ac.uk (Usenet administrator)
  8. Nntp-Posting-Host: uhura
  9. Organization: Aston University
  10. References: <1992Nov12.193707.27532@chpc.utexas.edu>
  11. Date: Fri, 13 Nov 1992 10:47:31 GMT
  12. Lines: 59
  13.  
  14. michael@chpc.utexas.edu (Michael Lemke) writes:
  15. : In article <EEIDE.92Nov12120339@asylum.cs.utah.edu> eeide%asylum.cs.utah.edu@cs.utah.edu (Eric Eide) writes:
  16. : >Scott Beckstead (scott@yarc.uucp) writes:
  17. : >
  18. : >
  19. : >I know of somebody who is doing research in this direction: me.  As part of my
  20. : >Masters degree I am modifying the C shell to be more tolerant of errors, both
  21. : >errors in syntax (e.g., typos) and semantics (e.g., inappropriate command line
  22. : >arguments).  My new shell keeps track of the user's command history in order to
  23. : >make accurate corrections.
  24. : >
  25. : >I have no hopes to solve all of the shell user interface problems, but I do
  26. : >hope to solve most of the common errors.  Just by fixing obvious typos my shell
  27. : >can fix 90% of the command line errors that I (and most people) make on a daily
  28. : >basis.
  29. : >
  30. : Well, fixing typos is neat but it is not the essential problem.  My
  31. : main complaint about Unix on the user interface level is that there is
  32. : no command line interpreter.  What I mean is that after the shell munged
  33. : your command line it is *completely* up to the program to interpret the
  34. : command line and there is no system function available to parse even
  35. : these `standard' options.  Some programs use one letter chinese (you
  36. : know, one character per word) and others (eg, find) use words (-print
  37. : -name).  And the real problem then starts when -l changes its meaning
  38. : from command to command, some commands need spaces between the option
  39. : and the argument, others don't, some take both, yech.  This would all be
  40. : solved if there were *one* system function that is used by all programs
  41. : instead of having every program duplicate more or less the same
  42. : functionality with different success.  And it would be great if you
  43. : could abbreviate commands (command completion of some shells it neat
  44. : but why is it neccessary in the first place?) and options (no need for
  45. : dynamic chinese anymore).
  46.  
  47. Could you say what operating system has this feature.
  48. (DOS dos the same, what does VMS do?)
  49. Also how the programmer is ment to use it.
  50. Does this belong in the operating system (thus resulting in command line
  51. options sitting in the PCB, yuck!! add a new 'standard' option rebuild 
  52. the system)
  53. : >I agree with Scott: There is no good reason that command shells shouldn't make
  54. : >more of an effort to understand the user.  
  55. : Computer:  Calculate the weather forecast for Sunday, Nov 15!
  56. : Yes, I would appreciate this... :-)
  57. : >Shells obviously can't divine the
  58. : >user's intentions in all cases, but that's not a good argument for failing to
  59. : >understand the user's intentions in *all* cases.
  60. : >
  61. : Does AI work now?
  62. -- 
  63. -------------------------------------------------------------------------
  64. Mark Evans                                   |evansmp@uhura.aston.ac.uk
  65. +(44) 21 565 1979 (Home)                     |evansmp@cs.aston.ac.uk
  66. +(44) 21 359 6531 x4039 (Office)             |
  67.