news@gremlin.nrtc.northrop.com (News Manager) (10/05/90)
From: jpl@charming.nrtc.northrop.com (Jeffrey P. Lankford <jlankford>)
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" <wfh58@leah.albany.edu>
"Ed Spire, The Workstation Group" <wrkgrp!ets@uunet.uu.net>
Alan Thew <QQ11@liverpool.ac.uk>
Keith DiNicola DINICOLK@ARIZVM1.CCIT.ARIZONA.EDU
Scott Ophof <NADWL@hdedh1.earn>
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 90274QQ11@LIVERPOOL.AC.UK (10/11/90)
In article <10586@gremlin.nrtc.northrop.com>, news@gremlin.nrtc.northrop.com (News Manager) says: > >From: jpl@charming.nrtc.northrop.com (Jeffrey P. Lankford <jlankford>) >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, ..... ...... >Third, there is a Unix REXX discussion list titled Unix-REXX and >available through Usenet i believe. Small correction here, not available via usenet (yet.....) List name is UREXX-L @ LIVERPOOL.AC.UK > Thanks for the summary. Alan Thew University of Liverpool Computer Laboratory Bitnet/Earn: QQ11@LIVERPOOL.AC.UK or QQ11%UK.AC.LIVERPOOL @ UKACRL UUCP : ....!mcsun!ukc!liv!qq11 Voice: +44 51 794 3735 Internet : QQ11@LIVERPOOL.AC.UK or QQ11%LIVERPOOL.AC.UK @ NSFNET-RELAY.AC.UK
jac@gandalf..llnl.gov (James Crotinger) (10/14/90)
One thing that never seems to get mentioned in these discussions of "Why use REXX when we have awk, csh, ..." is the ease of interprocess communication between REXX and applications with REXX ports. I haven't used REXX on UNIX. However I do use it on an Amiga which is, in many ways, similar to UNIX (multitasking, has command shells, pipes, etc.). On the Amiga, many uses have been found for REXX in which the most important feature of REXX is that it can tie together applicatons from different sources into an integrated environment. AREXX's popularity started because there was an editor that groked REXX and Tom Rokicki's TeX package groked REXX. Bingo, instant (or nearly so) integration between an editor and TeX. Mark an equation, hit a button and the previewer pops up displaying said equation. Pretty soon everyone began putting REXX ports in everything and, finally, Commodore decided to bundle AREXX with the next release of the OS. Do people in the VM/CMS world use REXX for this type of thing? (Obviously people don't on PC's 8-). How about on UNIX? Jim -- ----------------------------------------------------------------------------- James A. Crotinger Lawrence Livermore Nat'l Lab // The above views jac@gandalf.llnl.gov P.O. Box 808; L-630 \\ // are mine and are not (415) 422-0259 Livermore CA 94550 \\/ necessarily those of LLNL.
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (10/15/90)
In article <69733@lll-winken.LLNL.GOV> jac@gandalf..llnl.gov (James Crotinger) writes: > > Do people in the VM/CMS world use REXX for this type of thing? >(Obviously people don't on PC's 8-). How about on UNIX? Yes. On our VM/SP system, the editor comes from IBM with a REXX port. We have built REXX ports into several of our "most-used" programs. Works like a charm. (And this was before Amiga, let alone AREXX). Now that we have several thousands ofworkstations, we are still trying to recreate this functionality on Unix. [Oh no, I just started a flame war. :-)] > > Jim > >-- >----------------------------------------------------------------------------- >James A. Crotinger Lawrence Livermore Nat'l Lab // The above views >jac@gandalf.llnl.gov P.O. Box 808; L-630 \\ // are mine and are not >(415) 422-0259 Livermore CA 94550 \\/ necessarily those of LLNL. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!uunet!bnrgate!bcarh185!schow (613) 763-2831 ..!psuvax1!BNR.CA.bitnet!schow Me? Represent other people? Don't make them laugh so hard.
jdege@ (Jeff Dege) (10/15/90)
In article <3451@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: >In article <69733@lll-winken.LLNL.GOV> jac@gandalf..llnl.gov (James Crotinger) writes: >> >> Do people in the VM/CMS world use REXX for this type of thing? >>(Obviously people don't on PC's 8-). How about on UNIX? > >Yes. On our VM/SP system, the editor comes from IBM with a REXX port. >We have built REXX ports into several of our "most-used" programs. Works >like a charm. (And this was before Amiga, let alone AREXX). > >Now that we have several thousands ofworkstations, we are still trying to >recreate this functionality on Unix. > >[Oh no, I just started a flame war. :-)] > Is it just me, or is there another advantage that is getting missed? Unix makes for a very powerful system, but every tool is different. If you want to do anything complicated you have to deal with programming in the shell, that lispish stuff in gnu-emacs, awk, ad infinitum. One of the greatest things about REXX (well, AREXX, as I have no experience with other flavors) is the ability to use the SAME scripting language for the shell, term program, editor, database, etc. ----------------
terry@uts.amdahl.com (Lewis T. Flynn) (10/15/90)
In article <69733@lll-winken.LLNL.GOV> jac@gandalf..llnl.gov (James Crotinger) writes: > Do people in the VM/CMS world use REXX for this type of thing? >(Obviously people don't on PC's 8-). How about on UNIX? That's exactly what's done in VM/CMS and, not so obviously, on PCs with kedit and Personal Rexx (both from Mansfield). MS-DOS is pretty brain dead, but you can still do quite a bit. Terry