Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!ibmarc!rufus!drake.almaden.ibm.com!drake From: drake@drake.almaden.ibm.com Newsgroups: comp.lang.rexx Subject: Re: need a REXX-flavored version of getopt() Message-ID: <147@rufus.UUCP> Date: 5 Sep 90 06:33:21 GMT References: <90239.171548BOYDJ@QUCDN.BITNET> Sender: news@rufus.UUCP Distribution: comp Organization: IBM Almaden Research Center Lines: 39 Actually, getopt() is not entirely trivial to write/simulate in REXX. Doable, to be sure, but not trivial. REXX "parse" is perfect for doing first level parsing of command lines for systems with a CMS-ish command syntax style. In CMS, for example, it is conventional for command lines to look sort of like: command filename filetype filemode (OPTA OPTB OPTC 10 OPTD 20 OPTE ... Where "OPTA", "OPTB", and "OPTE" are arguments with no values. REXX Parse plus a "do" loop for the arguments works pretty well on this. But other systems have other command conventions. The same thing in UNIX might look like: cmd -abc10 -d20 -e inputfilepathname or cmd -a -b -c 10 -d 20 -e inputfilepathname or cmd -abed20 -c10 inputfilepathname Parsing this command line is a bit different, not as trivial, and not as well suited for REXX Parse. Getopt is better that Parse for this; you tell getopt what command line flags have arguments and point it at the command line; it tells you what the next flag found is and points you to it's argument if any (whether blank delimited or not). SO, getopt() is something that it'd be nice to have, even in REXX, on systems with unix-like command syntax. For that matter, something similar would be quite nice even on CMS; sure, Parse is great for: parse args filename filetype filemode junk '(' options ... but it's the parsing of "options" that is the hard part, and Parse rarely comes into play there. Sam Drake / IBM Almaden Research Center Internet: drake@ibm.com BITNET: DRAKE at ALMADEN Usenet: ...!uunet!ibmarc!drake Phone: (408) 927-1861