That's entirely possible, Bertram.  I don't have an ooRexx interpreter 
on the laptop I have here at the helicopter factory.  I was working 
with demonstrably imprecise documentation and unreliable wet-ware. :-)

So here is my question: Why have the DIRECTORY() function in the first 
place?

There are only five common shell directory functions that all 
hierarchical file systems need:

  1. display/change the current directory pointer (pwd/cd)
  2. list the contents of a directory (ls)
  3. create/delete a directory (mkdir/rmdir)
  4. change permissions/characteristics of a directory (chmod)
  5. attach/detach a directory to a filesystem (mount/umount)

These operations are well documented and universally implemented on 
all Unix platforms, if only somewhat so on the poorer "sortaPOSIX" 
derivatives.  For any Rexx implementation to provide a BiF for only 
one of the five functions is inadequate, imho.  That may be because 
(1) does nothing but manipulate environment variables, and requires no 
interaction with the filesystem per se.

A case could be made that all directory operations should be 
implemented in DIRECTORY().  The syntax of such a function would be no 
more complex than the current Stream() BiF.

There are enough minor variations in UNIX platforms that this might 
pose a major maintenance headache, however.  And let's not forget the 
existing name-collision issue with the Directory collection class.

I think Mike (and the IBM developers) did a stellar job of separating 
the "programming" functionality  of Rexx from any "platform" 
considerations, and I'd like to keep it that way.

The StreamI/O concept is elegantly platform-independent, in keeping 
with the abstracting of the arithmetic, terminal I/O, external command 
processing, and other environmental layers a Rexx interpreter needs. 
The fact that it can be employed on filesystems as disparate as z/OS, 
z/VM, and UNIX/Linux is testament to its thoughtful design.

I would not support a request for a TSO/REXX BiF to add a PDS to the 
SYSEXEC concatenation (the z/OS equivalent of 'PATH=$PATH/newdir'). 
Besides, the TSO/REXX function name-space is already cluttered with 
'way too many platform-dependent functions.

Nor do I see a need for the DIRECTORY() BiF, and feel that its 
presence provides no benefit over Address UNIX 'pwd' or Address UNIX 
'cd newdir'.  It doesn't even provide the same return codes.

And neither did the ANSI Rexx committee.

-Chip-

On 2/5/2016 7:24 AM, Bertram Moshier wrote:
> Hello,
>
> To the best of my knowledge the Directory Function does not create a
> new directory (ever), see #2 below.
>
> Bert.
>
> Chip,
>
> The trouble with this suggestion is that a simple typo could *create* a
> new directory, which must then be manually deleted.
> Of course one could make the same mistrake with "mkdir" itself, but
> there the irror would be more obvious :-)
>
> Les
>
> On 2/4/2016 1:26 PM, Chip Davis wrote:
>  > IMHO this is a software blivet (Def: "50 kg of manure in a 40 kg bag").
>  >
>  > The DIRECTORY() function is trying to do three things with the ability
>  > to return only one string:
>  >     1. Return the current directory
>  >     2. Create a new directory
>  >     3. Change to a new directory

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Reply via email to