Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!usc!isi.edu!gremlin!news From: news@gremlin.nrtc.northrop.com (News Manager) Newsgroups: comp.lang.rexx Subject: Summary of responses to query "Why use REXX in Unix environment?" Message-ID: <10586@gremlin.nrtc.northrop.com> Date: 4 Oct 90 18:30:44 GMT Reply-To: jlankford@nrtc.northrop.com Organization: Northrop Research and Technology Center Lines: 164 From: jpl@charming.nrtc.northrop.com (Jeffrey P. Lankford ) Path: charming!jpl Some time ago I posted a query to the group asking "Why use REXX in the Unix environment (where there may be other more suitable tools)?" I'm posting a summary now, since the trickle of responses seems to have dried up. The question was NOT intended to foment ecclesiastic debate ("my language can dance on the head of a pin better than yours"), but rather some consideration such as, "given some past or intended use of REXX, what are the pros/cons of using REXX in the Unix environment?" First, thanks to all who replied (in no particular order): "William F. Hammond" "Ed Spire, The Workstation Group" Alan Thew Keith DiNicola DINICOLK@ARIZVM1.CCIT.ARIZONA.EDU Scott Ophof Second, there is at least one version of REXX for Unix commercially available: The Workstation Group voice: 800-228-0255 6300 River Road, Suite 700 or 708-696-4800 Rosemont, Illinois 60018 fax: 708-696-2277 I have no experience with this product, but evidently some care went into building it; e.g., scripts are pre-parsed for more efficient interpretation. A version of XEDIT [ugh!] is also available. Third, there is a Unix REXX discussion list titled Unix-REXX and available through Usenet i believe. SET and SETTING: My background is primarily a Unix user, I recently found myself building communication systems for the VM environment. One of the very few useful features of VM i've found is REXX. However, it's not clear how useful REXX would be in a Unix environment without extensions to provide seamless integration into the environment. I envisioned two classes of applications: 1) using REXX as a command interpreter or "front-end" for invoking (Unix) commands [where tight coupling is mandatory], and 2) various kinds of (primarily text) processing [where the environment is may not be accessed except for file I/O and where REXX built-in string functions are available]. It seemed to me that: 1) REXX isn't suitable as an interactive command interpreter (no job control in the csh/ksh/Unix sense [not IBM batch "jobs"], no command history) or as non-interactive command interpreter (it has no syntax or semantics for i/o redirection, or piping or generic command control [PUSH, PULL, QUEUE can manipulate a double ended queue, but REXX assumes that re-directing i/o and diagnostics from commands is unique to each command {REXX's CMS heritage is showing}]) and 2) powerful tools for processing text are readily available (grep, sed, awk, ...) that obviate the need for programming such tasks with REXX. SUMMARY OF RESPONSES (re-phrased for anonymity): 1) Programmer's familiar with REXX don't have to re-learn everything to be productive in a Unix environment. Umm, okay, but learning new things makes life interesting. However, i'll admit that I used REXX to build POSIX-like front-ends to CMS commands to shield me from the ugliness (in the eye of this beholder) of VM. [Note: this is a heavily "environment dependent" application.] 2) REXX is a wonderful language regardless of it's run-time environment (especially compared to all those confusing Unix commands). Okay, i suppose it is a matter of taste. Some prefer a verbose English-like syntax (which made COBOL so successful), others prefer the lucidity of expressions like: File=`expr "$file" : 'lib\(.*\)' \| "$file" | tr -d '[._-]'` or cd $fromdir ; tar cf - . | ( cd $todir ; tar xf - ) or kill $SIG `/$HOME/bin/pick \`ps -ag | egrep "$*"\` | awk '{print $1}'` (:-) There's a smiley here - did everyone see it? 3) Good debugging facilities. I agree, if TRACE is a standard part if REXX. Although sh(1) and csh(1) have something similar, they aren't nearly as flexible. 4) Some users want to move (REXX) applications from CMS to Unix without major reprogramming effort (or any effort at all). I don't buy this one at all. The cost of using environment Y effectively must be accounted for when justifying moving an application from environment X to environment Y, or it implies that the environment is irrelevant, in which case why move? Also, almost any interesting or sophisticated application is going to invoke system commands (to copy a file or some such action); unless all such commands are supported as part of the REXX run-time environment, the code will have to be changed. Besides, you have to know (a little) something about Unix to run a Unix REXX interpreter. Replies > /dev/null. One an interesting line of discussion might be: what techniques can be applied to minimize and/or isolate environment dependencies of REXX programs? Out of perverse curiousity, has any UniREXX user ported Jim Foster's CMS CM.EXEC program that was posted to this newsgroup a while back. It seems typical of applications i would characterize as "environment dependent". My guess is that it can be ported, but not without significant modification. I also hazard a guess that inserting highlighted lines into a file (which essentially the gist of the program) can be done quite succinctly with sed(1). 5) Extensions to REXX to better couple into the Unix environment are possible (have been or can be done). Now this could be an interesting topic of discussion; e.g., what generic language extensions to REXX should be adopted to provide more powerful and flexible interaction with the environment in a portable manner? For example, a common environment dependent application need is: from a REXX script, execute any arbitrary command and on failure recover an error diagnostic code or message, while on success capture command output into a REXX variable. In the VM environment, this CANNOT be accomplished in general (this is a defect of VM, not REXX). However, the following cases can be accomplished: the CMS EXECIO command can be used to capture the output of any CP command (may be a diagnostic message if the command failed and CP has SET EMSG ON); for CMS commands, output can only be captured on the stack and only if the command specifically supports the STACK option (most commands don't). In the Unix environment, the Uni-REXX interpreter offers the following: an external procedure (POPEN) that accepts a command with arguments and directs output to the stack. Now suppose that this output is to be input to another command? How is the stack directed to the command input? Some external procedures might be coded to handle some of the semantics. Also, some effort appears to be underway to standardize I/O stream semantics (SAA compliant, REXX 4.0?, LINEIN and LINEOUT). But clearly, this is inadequate compared with the concise notation and powerful abstraction of the Unix shell standard input, output and error stream I/O re-direction, not to mention pipes (i thought i told you not to mention them.). Another related weakness of REXX as a command control language in the Unix environment is the lack of any multi-tasking semantics. Unix shells typically provide something fairly rudimentary (i.e., asynchronous background execution). 6) Some users have large applications doing numeric computation in REXX and they ... ... were born to suffer. 7) REXX evolved in CMS and not in Unix because CMS had no small, simple and powerful language and the Unix environment promotes the use of reusable code in various recombinations via piped filters. No disagreement here. In fact, my question was prompted by my observation that though REXX was one of the few decent features of VM, it didn't seem well suited to the Unix environment. BOTTOM LINE: In order to exploit a computing environment effectively, it's important to use tools well adapted to that environment. REXX really needs some (perhaps modest) enhancements to provide better integration into the Unix environment. I don't see that REXX brings any nifty abstractions to the party, but it's a big party with enough room for everyone's peccadillos. Jeff Lankford Northrop Research and Technology Center 213/544-5394 One Research Park, Palos Verdes Peninsula, CA 90274