home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / wizards / 4740 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.5 KB
  1. Xref: sparky comp.unix.wizards:4740 comp.unix.shell:4744 comp.unix.misc:4207
  2. Path: sparky!uunet!vtserf!black-ice.cc.vt.edu!valdis
  3. From: valdis@black-ice.cc.vt.edu (Valdis Kletnieks)
  4. Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
  5. Subject: Re: The Problem with UNIX
  6. Message-ID: <9685@vtserf.cc.vt.edu>
  7. Date: 17 Nov 92 02:23:12 GMT
  8. References: <EEIDE.92Nov12120339@asylum.cs.utah.edu> <1992Nov12.193707.27532@chpc.utexas.edu> <EEIDE.92Nov12154722@asylum.cs.utah.edu>
  9. Sender: news@vtserf.cc.vt.edu
  10. Followup-To: comp.unix.wizards
  11. Organization: Virginia Tech, Blacksburg, VA
  12. Lines: 20
  13.  
  14. In article <EEIDE.92Nov12154722@asylum.cs.utah.edu> eeide%asylum.cs.utah.edu@cs.utah.edu (Eric Eide) writes:
  15. >
  16. >It sounds as if you are proposing the invention of an application-independent
  17. >command line parser that does more than just syntactic processing (as provided
  18. >by getopt()).  This would definitely be interesting -- but is it really
  19. >possible?  What would it look like?  What would the universal meaning of `-l'?
  20.  
  21. Didn't the opsys on the DEC-20 (twenex?) do this?  I think it even
  22. allowed 'completion' of more than just filetypes - however, it *did*
  23. involve firing up the binary of the program a bit earlier because
  24. there was some incestuous relationship between the command's code
  25. and the command line interpreter.  Essentially, the command had
  26. a section of code that could be called by the interpreter to
  27. "assist" parsing.
  28.  
  29. Twenex gurus feel free to correct me.
  30.  
  31.                 Valdis Kletnieks
  32.                 Computer Systems Engineer
  33.                 Virginia Tech
  34.