home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / wizards / 4635 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  2.9 KB
  1. Xref: sparky comp.unix.wizards:4635 comp.unix.shell:4659 comp.unix.misc:4126
  2. Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
  3. Path: sparky!uunet!think.com!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!hermes.chpc.utexas.edu!michael
  4. From: michael@chpc.utexas.edu (Michael Lemke)
  5. Subject: Re: The Problem with UNIX
  6. Message-ID: <1992Nov12.193707.27532@chpc.utexas.edu>
  7. Organization: The University of Texas System - CHPC
  8. References: <aldavi01.721333614@starbase.spd.louisville.edu> <1992Nov11.194557.16258@yarc.uucp> <EEIDE.92Nov12120339@asylum.cs.utah.edu>
  9. Date: Thu, 12 Nov 92 19:37:07 GMT
  10. Lines: 51
  11.  
  12. In article <EEIDE.92Nov12120339@asylum.cs.utah.edu> eeide%asylum.cs.utah.edu@cs.utah.edu (Eric Eide) writes:
  13. >Scott Beckstead (scott@yarc.uucp) writes:
  14. >
  15. >
  16. >I know of somebody who is doing research in this direction: me.  As part of my
  17. >Masters degree I am modifying the C shell to be more tolerant of errors, both
  18. >errors in syntax (e.g., typos) and semantics (e.g., inappropriate command line
  19. >arguments).  My new shell keeps track of the user's command history in order to
  20. >make accurate corrections.
  21. >
  22. >I have no hopes to solve all of the shell user interface problems, but I do
  23. >hope to solve most of the common errors.  Just by fixing obvious typos my shell
  24. >can fix 90% of the command line errors that I (and most people) make on a daily
  25. >basis.
  26. >
  27.  
  28. Well, fixing typos is neat but it is not the essential problem.  My
  29. main complaint about Unix on the user interface level is that there is
  30. no command line interpreter.  What I mean is that after the shell munged
  31. your command line it is *completely* up to the program to interpret the
  32. command line and there is no system function available to parse even
  33. these `standard' options.  Some programs use one letter chinese (you
  34. know, one character per word) and others (eg, find) use words (-print
  35. -name).  And the real problem then starts when -l changes its meaning
  36. from command to command, some commands need spaces between the option
  37. and the argument, others don't, some take both, yech.  This would all be
  38. solved if there were *one* system function that is used by all programs
  39. instead of having every program duplicate more or less the same
  40. functionality with different success.  And it would be great if you
  41. could abbreviate commands (command completion of some shells it neat
  42. but why is it neccessary in the first place?) and options (no need for
  43. dynamic chinese anymore).
  44.  
  45. >I agree with Scott: There is no good reason that command shells shouldn't make
  46. >more of an effort to understand the user.  
  47.  
  48. Computer:  Calculate the weather forecast for Sunday, Nov 15!
  49.  
  50. Yes, I would appreciate this... :-)
  51.  
  52. >Shells obviously can't divine the
  53. >user's intentions in all cases, but that's not a good argument for failing to
  54. >understand the user's intentions in *all* cases.
  55. >
  56.  
  57. Does AI work now?
  58.  
  59. -- 
  60. Michael Lemke
  61. Astronomy, UT Austin, Texas
  62. (michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
  63.