HDTenEightyP/NetNews huggingface dataset:
From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: Capturing System Command Output (was: SH Backquote)
Organization: The Workstation Group
Date: Tue, 1 Sep 92 14:59:48 GMT

ets@wrkgrp.COM (Edward T Spire) writes:
: 
: AREXX does contain some features that do not conform to Cowlishaw's
: rules.  In some cases this is somewhat understandable, such as the
: issue we're discussing here, where Cowlishaw gave no guidance, and each
: implementer was forced to roll his own.  In other areas (such as I/O)
: Bill Hawes simply did something he thought was better than what
: Cowlishaw had suggested.  He may have been "right" about that, but it
: is causing some problems in the ANSI REXX efforts.

Someone just reminded me that AREXX I/O differs from the standard not
because Bill just plain wanted to do something he thought was better,
but because the only REXX model he had was CMS, so he had to roll his
own I/O.  If Bill had had a copy of "The REXX Language" in hand when
he was writing AREXX, it may well have turned out quite differently.

-Ed
Newsgroups: comp.lang.rexx
Newsgroups: comp.lang.rexx
Date:         Fri, 28 Aug 1992 13:03:23 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              28 Aug 1992 16:24:57 GMT from <SCHMIDT@LSTC2VM.STORTEK.COM>

I think systems where you can have trivia contests like:  guess what
this command (or program) does?   are a real kick in the pants!

Unfortunately, I also have work to do.  Too bad I can't spend all day
on such a fun system!
From: BEBO@SLACVM.SLAC.STANFORD.EDU (Bebo White)
Newsgroups: comp.lang.rexx
Subject: REXX Symposium Listserv List
Date: 26 Aug 92 11:01:35 GMT
Organization: Stanford Linear Accelerator Center

A Listserv list has been established at SLACVM for the discussion of
REXX Symposium planning issues. The name of this list is:
         REXSYM-L@SLACVM

The REXX Symposium Planning Committee welcomes any and all input regarding:
         * the Symposium dates
         * the program
         * locations and accomodations
         * etc., etc.

Hopefully, this list will serve as a useful mechanism for obtaining such
input.

Bitnet users can subscribe to this list via the TELL command:
       TELL LISTSERV@SLACVM SUBSCRIBE REXSYM-L your_real_name_in_mixed_case
  e.g., TELL LISTSERV@SLACVM SUBSCRIBE REXSYM-L J. Danforth Quayle
the account id that originates this request will be the e-mail address
to which list discussion is directed.

Non-Bitnet users can subscribe by sending e-mail to
LISTSERV@SLACVM.SLAC.STANFORD.EDU with a blank Subject line and the
SUBSCRIBE ...... command as the first and only line in the mail body.

If both of these techniques should fail, please send mail to me and I'll add
you to the list.

For those unfamilar with Listserv, contributions to the discussion/list are
made by sending e-mail to REXSYM-L@SLACVM or REXSYM-L@SLACVM.SLAC.STANFORD.EDU

If you are a past attendee, a possible future attendee, or just an observer
of the REXX Symposium, please make your thoughts know. The Symposium
planning committee wants to make future symposia the best they can be.


Bebo White
---> the opinions expressed are mine alone and not necessarily those
     of SLAC, Stanford University or the DOE
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: Re: Blanks, REXX, and portability...
Organization: Draper Laboratory
Date: Thu, 27 Aug 1992 14:03:00 GMT

In article <ANDERS.92Aug26105620@lise3.lise.unit.no>,
anders@lise3.lise.unit.no (Anders Christensen) writes:

>You ftp a file from Unix to CMS. You don't use binary mode, since the
>ASCII code would be unreadable on a EBCDIC machine anyway. So you use
>text mode, and your CMS machine translates the text to EBCDIC,
>including translating the tabs to spaces. No problem.

Not so (at least with MVS).  ASCII tabs are translated to EBCDIC tabs.

[comments on parsing the output of the "who" command]

As long as we're talking Unix, you can do

  "who | expand"

as a portable (from one Unix to another, anyhow) workaround.


--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Organization: Penn State University
Date: Tue, 25 Aug 1992 13:59:49 EDT
From: Christopher Sacksteder <CJS@psuvm.psu.edu>
Newsgroups: comp.lang.rexx
Subject: Re: REXXCOMP versus EXECUPDT (NOUPDATE NOCOMMENTS

In article <REXXLIST%92082510304051@OHSTVMA.IRCC.OHIO-STATE.EDU>, Richard
Varenas <VARENAS@DUVM.BITNET> says:

>How/where can I get a copy of REXXCOMP?

An older copy is available from LISTSERV at PSUVM (e.g., tell listserv at
psuvm get rexxcomp package).  You'd have to fit the updates to your level
of CMS.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
From: anders@lise3.lise.unit.no (Anders Christensen)
Subject: Re: Eric's question
Organization: University of Trondheim, Norway
	<1992Aug29.170623.1@sejnet.sunet.se>
Date: 29 Aug 92 19:42:48

In article <1992Aug29.170623.1@sejnet.sunet.se> eric@sejnet.sunet.se (Eric Thomas) writes:
> In article <ANDERS.92Aug29050537@lise3.lise.unit.no>, anders@lise3.lise.unit.no (Anders Christensen) writes:

> Noooooooooooooooooooo! Forget the NAMES file, [...]

Fine, but it really doesn't change anything with respect to the actual
parse clause.

>			 Parse var data a b . ' A('c')' d

You use a Space character in the pattern to denote a whitespace.
Yes, it creates problems when Tab and Space are both whitespace, and
parse can't match varying patterns. But the situation will not be any
better if Rexx interpreters under Unix do not recognize Tab as a
whitespace character. 

Your use of Space in templates make an Unix interpreter trip when it
encounters a Tab. Recognizing Space as the only whitespace will make
it trip whenever it encounters a Tab.

> >    * You want to be able to use the program on several platforms,

> No, [...]

OK, then your program will continue to work on the CMS machine, since
the assumptions it makes are correct in that environment. 

If you move to Unix machine, then you want to write the rexx script
from scratch (that's how I understand your 'No'). Then you should use a
dataformat more suitable for the Unix environment. 

> How do I tell the interpreter which of my spaces mean SPACE and which mean
> white space, given that REXX must accept any literal string?

If you tell it to seek for a literal string, it should seek for a
literal string. If you want to tell it to seek for a particular string
containing whitespace, then I don't think parse is able to do that.

Adding regexps would solve this problem by adding more power, but it
might also adds too much complexity to justify it. There are probably
very different opinions about that.

>                                              REXX is designed to be easy
> to learn by people without a DP background. Regular expressions are not
> precisely intuitive for this type of people :-)

Sure, I agree. But Unix uses Tab as a whitespace character. If Rexx
interpreters under Unix don't recognize that, that is a problem with
Rexx under Unix.

-anders
Newsgroups: comp.lang.rexx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Blanks vs white space...
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Sat, 29 Aug 1992 17:02:32 GMT

Frankly, I am a bit surprised at the sheer amount of bytes of arguments,
proposals and counter-proposals that this fairly simple "blanks and whitespace"
problem has generated. Personally I can't see what is so complicated about it
that requires proposals of more than 200 lines which touch about each and every
function in the language, and what is so controversial about making it easier
for unixers to process tabs et al the way they are used to - without breaking
anything, of course.

It is a fact that most non-EBCDIC systems use tabs in source code, and won't
change their minds just because of REXX. So REXX interpreters running on ASCII
systems should accept tabs as valid white space delimiters in source code. That
is, if I enter a tab rather than 8 spaces before "Do i = 1 for 10", it should
make no difference to the interpreter. Anything else will cause trouble to the
end users, especially those who don't know the magic formula to tell vi to
expand tabs.

A tab in a comment is obviously ignored, just like a blank in a comment or a
W in a comment. I can't believe this issue was even raised!

A tab in a quoted string is a tab, not a blank, just like in C and other unix
languages. Programmers will probably avoid putting tabs in quoted strings,
because they look like blanks when editing the file. In C they would use \t, in
REXX I guess they will code '09'x. I don't see any problem here.

When I ask the REXX interpreter to locate a string containing a blank, either
via PARSE or POS or other similar function, I probably really mean blank, not
white space. Even if I did mean white space, I would be making a major mistake
in assuming that the blank I type should be interpreted as white space: one of
the cornerstones of REXX is that you can manipulate strings of any length and
containing any possible character, from 00 to FF. If blank in a literal means
"any white space will match", there is no way to search binary data for
something which contains a genuine blank, and this is obviously a very serious
problem. So we keep PARSE and built-in functions exactly as they are today.

To solve the problem of system commands which return tabs and files which
contain tabs and have to be parsed as words, we add a very powerful, very
complicated built-in function, the type which takes hours to master:

                                  expand(x)

This function expands tabs, throws away the square-root-of-pi-div-2-emm-space
characters in the latest lame excuse for nice business trips the ISO came up
with, and returns something which can be directly used with all the usual PARSE
and POS functions. One might want to add an optional parameter or two to
specify the tab columns and whether non-linear white space characters such as
CR/LF should be translated to blanks or left intact, but you get the picture.

My turn to be flamed now :-)

  Eric
Newsgroups: comp.lang.rexx
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: Re: PARSE wishlist/brainstorming
Organization: Draper Laboratory
Date: Thu, 27 Aug 1992 13:46:00 GMT

In article <1992Aug24.193441.9572@hou.amoco.com>,
zjlc12@hou.amoco.com (Jerry Campbell) writes:

>I may retract my original idea.  Perhaps some new parsing template elements?
>
>        Parse Var stream With Stem "fruits:"  nuts.(iterative_stem_template)
>
>Where iterative template could contain strings that would mean, iterate on the
>stem when this string is encountered.  Or numbers which would be somewhat similar
>to the existing N or +N elements.  Only N means start at stem index N and
>+N means iterate over the stem N times.
>
>        stream = "fruit:  apple, orange, plums, banana" ,
>                 "nuts:   walnut, almond, filbert"
>
>        Parse Var stream With Stem "fruit:" fruits.("," 1 +2) ,
>                                   "nuts:"  nuts.("," 1 +2)
>
>This would retain a certain amount of symmetry with the existing parsing elements
>which is, to my mind, a good thing.  And at the same time not collide with
>the normal parsing stuff.  OOOOh it also means we can dump the proposed STEM
>keyword!  Even cleaner yet!
>
>        Parse Var stream "stream_positioner" n stem.(stem template) +n
>                         ^^^^^^^^^^^^^^^^^^^^^                      ^^
>                         (regular parsing stuff)
>
>        Parse Var stream "stream_positioner" n stem.(stem template) +n
>                                               ^^^^^^^^^^^^^^^^^^^^
>                                               (new parsing stuff)
>What do you think?  More workable?  How tough is this syntax to interpret?

I think this is getting awfully complex (I hear creatures feeping).
Not as crufty as Lisp FORMAT yet, but getting close.  One advantage
of REXX is its readability - this strains it somewhat.

I'd probably prefer to do it in multiple stages:

   Parse Var stream    "fruit:"  fruitlist "nuts:" nutlist
   Parse Var fruitlist  Stem "," fruit.
   Parse Var nutlist    Stem "," nut.

Looks pretty clear to me that way.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Tue, 1 Sep 1992 15:01:06 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...

On Tue, 1 Sep 1992 16:18:42 GMT Edward T Spire said:
>: I later wrote a little
>: UNIX REXX program (see below) to investigate this anomalous (to me)
>: phenomenon.  I was shocked to discover that this UNIX REXX
>: interpreter considered 41 of the 256 possible 8-bit codes in the
>: range '00'X to 'FF'X to be blanks!  41? Where did this come from?
>
>I ran your program on an RS/6000 and got 6 white space characters,
>not 41.  Then I ran it on a older Sun and got 48!  On a newer Sun
>I got 7, on an HP I got 10, and on SCO I got 44.

Now there is an operating system you can really sink your teeth into!
From: zjlc12@hou.amoco.com (Jerry Campbell)
Newsgroups: comp.lang.rexx
Subject: Re: Eric's question
Date: 31 Aug 92 14:47:32 GMT
Reply-To: zjlc12@hou.amoco.com
Organization: Amoco

In article 1@sejnet.sunet.se, eric@sejnet.sunet.se (Eric Thomas) writes:
>Let's face it, all you need is an expand() function. You don't need regexp, you
>don't need to change every single function and internal aspect of the language,
>you don't need to make assumptions about when the programmer wants TAB to be a
>word separator and the case where he was reading a makefile and wants TAB to be
>a TAB, you don't need to add OPTIONS qualifiers. All you need is to expand the
>stupid tabs whenever you want them to stand for blanks, ie after acquiring text
>data from an external source like a file or a system command. Then it is clear
>to all the REXX programmers on the planet what your program does, and there is
>no unexpected pitfall or anything like that.
>
>  Eric

I agree.  Let operating system quirks be handled by the particular Rexx
implementation.  If a Rexx Uni* implementor wants to be nice and help 
programmers/users handle whitespace, then this is the form the help ought
to take ====>>  expand().  I cast my vote for whatever its worth with this
side.

---
Jerry Campbell   reply to: zjlc12@hou.amoco.com 
Amoco Corp. ISD  SSS/Graphics
Houston, Tx.     713/556-7036
From: pmuellr@VNET.IBM.COM ("Pat Mueller")
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 27 Aug 92 02:40:05 GMT

If it's useful to be able to handle it BOTH ways - make it a
value of the OPTIONS statement.  IBM rexx implementations already
have option 'words' for DBCS enablement.

Patrick Mueller
pmuellr@vnet.ibm.com
Programming Systems, IBM Cary, NC
Newsgroups: comp.lang.rexx
From: paulg@resmel.bhp.com.au (Paul Gallagher)
Subject: Limitations of SysGetEA
Keywords: sysgetea
Organization: BHP Research - Melbourne Laboratories, AUSTRALIA
Date: Fri, 4 Sep 1992 02:29:57 GMT

Under IBM OS/2 v2.0...

...I ran into a wall with SysGetEA(). It seems to work only with
files, not directories. This may be a "feature", but I do not
understand why the distinction persists. The function actually
returns a non-zero code (i.e. error) rather than returning a (null)
extended attribute.

Has anyone looked into this problem before, or know what plans may be
in the air?

regards,
paulg
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Tue, 25 Aug 1992 23:21:29 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Blanks, REXX, and portability...
Comments: To: REXX Discussion list <REXXLIST@uga.cc.uga.edu>,
              REXX on Unix discussion list <UREXX-L@Liverpool.ac.uk>

Question:  When are blanks not only the space character?
Answer:    In any case in Unix.

In "The REXX Language" (Mike Cowlishaw) and most other REXX
publications meant for CMS and equivs, the character known as
"space" and the concept of "blanks" are used interchangeably.

For CMS-REXX (and analogous implementations), this poses no
problems.  The space character is the *only* character defined
as a "blank".
(Note that I'm *not* talking about non-printable characters,
and the space char *is* a printable character!)

Under Unix however, the tab character (and some others) are
considered "blanks", though it's called "whitespace" there.
At least some REXX implementations for Unix recognize more than
the space char as whitespace.  And REXX on the PC recognizes at
least the space char and the tab char as whitespace/blank...

My point?
I would hate to have to port to CMS any REXX program written for
Unix (or PC); to have a program fail due to something like this
would not be very easy to debug...

My suggestion?
In the interest of increasing the chance of successful porting, to
request the ANSI-REXX committee to define that the *only* blank/
whitespace recognized in standard REXX is the SPACE character (ASCII
hex-20, EBCDIC hex-40).

Your comments?  :-)


Regards.
$$/
Newsgroups: comp.lang.rexx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re: do over stem
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Wed, 26 Aug 1992 17:29:15 GMT

In article <ANDERS.92Aug26061644@lise3.lise.unit.no>, anders@lise3.lise.unit.no (Anders Christensen) writes:
> For every new feature in Rexx, the definition of the language
> increases, and the language becomes more complicated for new users to
> learn. For those who already know Rexx well (includes most of the
> readers of this group), the addition of a simple feature might not be
> a big deal. But for language itself, the accumulation of many simple
> features can make Rexx big, complex and difficult to learn for new
> users.

A language which contains such useless constructs as '1101'b (for people who do
have to use binary constants but don't know that 1101 = 'D'x, and don't mind
getting syntax errors in programs which used to work before and did things like
SAY 'a='a', b='b) doesn't need to concern itself with the impact of additions
like DO OVER which fit so well into the existing syntax.

> It would work something like: <var> is 'iterated through' the tails
> which the stem <stem.> had at the moment when the do-loop was entered.

You would have to make a copy of all existing tails when the loop was entered,
which costs CPU time, memory and makes the code more complex (you have to make
sure to release it when the loop is exited, and so on). When coding this, you
will have to find a compromise between o(n2) algorithms like 'list = list
newtail', which are unacceptable for large stems, and chained-list like
algorithms which are more linear but allocate a bunch of small chunks of
storage which then have to be released (you would end up with the same kind of
"slowing factor" at the end of the loop as dropping the stem would give you).

I'd rather just be told that I can't drop elements of the stem while the loop
is running (dropping individual stem elements is useless and behaves
illogically anyway - they become undefined instead of reverting to the stem's
default value), and that either I can't add new tails until the loop is over or
I will not see them. The former can be enforced with a run-time error if you
attempt to modify a stem being "done over", the latter could be done by
"dating" stem elements with a counter incremented by each "do over" and simply
skipping tails created after your do started. The important point is that it
should be predictable, should not make the new function unusable, but should be
reasonably easy to implement.

  Eric
Newsgroups: comp.lang.rexx
From: giguere@csg.uwaterloo.ca (Eric Giguere)
Subject: Re: Stealing ideas from Unix (was Re: Blanks, REXX, and portability...)
Organization: Computer Systems Group, University of Waterloo
Date: Tue, 1 Sep 1992 20:50:09 GMT

In article <1992Sep1.210452.1@sejnet.sunet.se> ERIC@SEARN.SUNET.SE writes:
>I've re-read my posting 3 times and I frankly can't see where it supposedly
>says that mine is better than yours. All I see is a statement that it is a
>pointless effort to attempt to port a large REXX application from system X to
>system Y, because REXX (like all scripting languages) is full of system
>commands (like LISTFILE, EXECIO, COPYFILE, ls, grep, mv) which generally work
>only on one system. And the reason I pointed it out is that it is not obvious
>to many people, especially people with a lot of experience in "traditional"
>languages. A 25-30k lines FORTRAN 77 program written for CMS is probably much
>easier to port to unix than to rewrite from scratch, this is true of most
>standardized languages, but it doesn't work with REXX, no matter how compliant
>your interpreters are.

Sigh.  I wasn't commenting on your _specific_ posting, just the general
tone that this "blanks" debate has taken on at times.

And you're right about REXX scripts being mostly unportable.  Certainly
I couldn't port my ARexx scripts to CMS.  Not unless I also ported all
the applications that use those scripts.

-- 
 Eric Giguere                                    giguere@csg.UWaterloo.CA
          So is Windows NT short for "Windows, NOT?"  
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 27 Aug 1992 13:10:36 CST
From:         Jim Glover <SPJRG@VM.CC.LATECH.EDU>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: rexxlist@uga.cc.uga.edu

>However, it has been my experience (however limited you might perceive
>that to be) that the format of the data is seldom constant, so, it seems
>that *MOST* CMS REXX programmers parse data on the basis of white-space-
>delimited words and/or the presence of known constants at least as often
>as they parse data on the basis of hard-coded "column numbers".

I'd like to add my "Amen!"  I too am a CMS REXX programmer, and I can
tell you that I *rarely* parse based on column position.  I do make an
exception sometimes when data will be located in a particular position
without any delimiting white space at all, or when data will be located
in a particular position and the preceeding fields may unpredictably
be blank, thus preventing my knowing how many .'s to include in some-
thing like  PARSE VAR INPUT . . . Stuff_I_Want .
I'd guess that such cases represent about 1% of what I do in REXX.  The
rest of the time, I'm using white space just like everyone else.
                            --Jim
From: Andre_Lehovich@Brown.Edu (Andre Lehovich)
Newsgroups: comp.lang.rexx
Subject: do over stem
Date: Sun, 23 Aug 1992 21:47:30 EDT
Organization: Brown University, Providence, Rhode Island USA
NNTP-Posting-Host: brownvm.brown.edu
News-Software: BNN via BNN_POST v1.0 beta

Our news software had problems when I posted this.
Apologies if you see it twice.

As long as we're discussing proposed additions to the ANSI
standard, here's my pet peeve:

I want to be able to loop a variable over a stem, like so:

foo.1 = 'alpha'
foo.2 = 'beta'
foo.4 = 'delta'
do i over foo.
  say i
end

which would yield as ouput:
  1
  2
  4

I vaguely remember this being discussed before; are there
any problems with adding this to the language?  If so, what
are they?

Btw, my opinion on the usenet<->rexxlist gateway has gone
up.  There's been some good rexx discussion going on.

Andre_Lehovich@Brown.Edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 3 Sep 1992 19:01:21 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: newbie rexx programmer asks silly questions
              3 Sep 1992 22:36:28 GMT from <martinc@GROVER.CS.UNC.EDU>

On Thu, 3 Sep 1992 22:36:28 GMT Charles R. Martin said:
>
>Now, what about DOS rexx implementations?  personal REXX from Mansfield
>Software in CT is the only one I've seen mentioned so far....

Probably for good reason.  Personal REXX is an outstanding product.
Nevermind that it was written to please me (I goaded Charles Daney and
Kevin Kearney to start on the original product).  Charles takes a great
deal of pride in his work and Personal REXX shows it.   Try it, you'll
love it!
Newsgroups: comp.lang.rexx