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