Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: shell architecture (to glob or not to glob)
Message-ID: <3151@crdos1.crd.ge.COM>
Date: 24 Jan 91 16:25:19 GMT
References: <1991Jan14.013815.11419@ims.alaska.edu> <11314@lanl.gov> <5340@idunno.Princeton.EDU> <1991Jan14.170115.17178@Think.COM> <360@bria> <1991Jan17.185527.9824@Neon.Stanford.EDU> <365@bria> <1991Jan21.200544.29795@Neon.Stanford.EDU> <62271@bbn.BBN.COM>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 18

In article <62271@bbn.BBN.COM> pdsmith@spca.bbn.com (Peter D. Smith) writes:

| VMS, the 'shell' of overwhelming choice on DEC platforms :-), can already
| do this.  It's just a question of time before everyone and their kid
| Standards Organization writes any number of incompatible versions for Unix.

  My impression of the way the VMS DCL works is that it's something like
ANCSI C procedure prototypes, specifying the valid options and
positional parameters, what's required, what's optional, etc.

  This isn't totally unique to VMS, although the implementation is.
Using functions, getopts, and typeset in ksh, one can get arg and option
checking and other stuff. It's certainly not table driven, but the
functionality is there, and people use it.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
  "I'll come home in one of two ways, the big parade or in a body bag.
   I prefer the former but I'll take the latter" -Sgt Marco Rodrigez