home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / wizards / 4673 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  4.9 KB
  1. Xref: sparky comp.unix.wizards:4673 comp.unix.shell:4691 comp.unix.misc:4152
  2. Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
  3. Path: sparky!uunet!gumby!wupost!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: <1992Nov13.223242.14442@chpc.utexas.edu>
  7. Organization: The University of Texas System - CHPC
  8. References: <1992Nov12.193707.27532@chpc.utexas.edu> <1992Nov13.104731.29328@aston.ac.uk> <1992Nov13.180132.141@u.washington.edu>
  9. Date: Fri, 13 Nov 92 22:32:42 GMT
  10. Lines: 87
  11.  
  12. In article <1992Nov13.180132.141@u.washington.edu> donn@carson.u.washington.edu (Donn Cave) writes:
  13. >evansmp@uhura.aston.ac.uk (Mark Evans) writes:
  14. >
  15. >|michael@chpc.utexas.edu (Michael Lemke) writes:
  16. >...
  17. >|: Well, fixing typos is neat but it is not the essential problem.  My
  18. >|: main complaint about Unix on the user interface level is that there is
  19. >|: no command line interpreter.  What I mean is that after the shell munged
  20. >|: your command line it is *completely* up to the program to interpret the
  21. >|: command line and there is no system function available to parse even
  22. >|: these `standard' options. ...
  23. >
  24. >| Could you say what operating system has this feature.
  25. >| (DOS dos the same, what does VMS do?)
  26. >| Also how the programmer is ment to use it.
  27. >| Does this belong in the operating system (thus resulting in command line
  28. >| options sitting in the PCB, yuck!! add a new 'standard' option rebuild 
  29. >| the system)
  30. >
  31. >VMS does in fact have a command interpreter, DCL.  
  32.  
  33. When I wrote my little remark up there I actually had VMS in mind.  
  34. Several people pointed out in the meantime that there is getopt (3), of 
  35. which I wasn't aware at the time of writing.  Well, that is a least a 
  36. start but as some people also remarked it is somewhat limited and
  37. overkill in other cases.  Does it allow optional parameters (I know 
  38. getopts in the Bourne shell does not)?
  39.  
  40. >From a programmer's point
  41. >of view, it's a callable system interface that yields up the parsed command
  42. >line.  From the user's point of view, it's a fairly regular command language
  43. >with consistent rules about abbreviations and optional parameters.
  44. >Unfortunately, it's pretty weak as a programming language, 
  45.  
  46. True, but we weren't talking about programming although that is a very 
  47. important aspect too.
  48.  
  49. >but it does have
  50. >"lexical functions" built in to do things like parse file names and wildcards,
  51. >get system information of various kinds and do some text manipulation.
  52.  
  53. Although definately not as flexible as Unix it is consistent on every level,
  54. i.e., if you parse a filename with f$parse/f$scan from DCL or call 
  55. lib$find_file from a program the behavior is identical.  And concerning 
  56. command line parsing the CLI$ routines are easily callable from any 
  57. language and can even be used for the internal command driven interface 
  58. of your application program.  Their use is a little complex but command 
  59. line parsing is a complex problem -- lex isn't easy to use either (I 
  60. can't).
  61.  
  62. >
  63. >I'm not strong on VMS internals, but I don't think the command line goes
  64. >into a PCB, but rather is stored in a DCL supervisor area per user - VMS
  65. >may be a little more complex than UNIX in this respect.  There's a command
  66. >history, which presumably is also stored there.  Changing the command set
  67. >does not require rebuilding the system, and users may adopt their own
  68. >command tables or add their own customizations.  Updating the command table
  69. >can be problem, since the change doesn't affect current jobs, but that's
  70. >an implementation issue.
  71. >
  72. >Probably the biggest issue for the programmer is that DCL doesn't expand
  73. >wild cards.  VMS applications expand wild cards using file system services,
  74. >which is much harder programming work but gives you a lot more control over
  75. >the semantics of the operation, as opposed to (int argc, const char **argv).
  76.  
  77. Well, it is really not that hard to do.  Just call lib$find_file in a
  78. loop until it returns RMS$_NMF.  You'll need the loop anyway.
  79.  
  80. >For example, one may use the file specification in one parameter to supply
  81. >defaults for the specification in another parameter, further controlling
  82. >whether the defaults are to be applied using output (new) file or input
  83. >(old) file semantics.  That makes "RENAME *.C .C-DIST" a natural idiom in
  84. >VMS, where in UNIX the same operation ("how do I rename a group of files")
  85. >regularly generates questions on this news group.  It does however mean
  86. >that applications accept wild cards only if the programmer invested the
  87. >time.
  88.  
  89. That is certainly true.  But I am very much convinced that none of the 
  90. typical Unix users understand that the shell is expanding the wildcards
  91. and they will be rather very surprised to see echo * produce a strange 
  92. ls listing.  On the other hand not many people completely understand the
  93. sticky defaults you just described either.
  94.  
  95. -- 
  96. Michael Lemke
  97. Astronomy, UT Austin, Texas
  98. (michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
  99.