A typical call to SysFileTree might be something like:

  Call SysFileTree '*','F.','FO'

I'm wondering if it would be possible to emulate this in an external
REXX routine. The hard part would be passing that 'F.' as the name of
the stem *in the callers variable pool* that would be used for the
results.

If it matters, I'll be using Open Object Rexx 4.0.1 for the next 3
weeks. Then 4.1.0

I'm all but certain that I'm asking the impossible here. Having been
passed the *name* of a stem, an external routine then uses that name
to update the named stem in the *callers* variable pool.

My plan would be to call my routine "FileTree", then use my editor to
blindly change all occurrences of SysFileTree to FileTree across my
entire code base. Apart from where I defined my "FileTree" routine, of
course.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

Swifty wrote:
>A typical call to SysFileTree might be something like:
>     Call SysFileTree '*','F.','FO'
> I'm wondering if it would be possible to emulate this in an external
> REXX routine. The hard part would be passing that 'F.' as the name of
> the stem *in the callers variable pool* that would be used for the
> results.

Won't the "use arg" instruction do what you want?  Untested:

invoker:
  files.0=0
  call FileTree "*" , files. , 'FO'

In an external file:

  FileTree: procedure
    use arg pattern , files. , options
    /* "pattern" and "options" are passed by value */
    /* "files." is passed by reference */
    call SysFileTree pattern , files. , options
    return

Aside: it has always struck me as inconsistent that only stem variables are 
passed by reference on "use arg"; simple variables are still passed by value, 
thereby precluding the ability elegantly to update multiple simple variables 
in the invoker (emphasis on "elegantly" here; of course one can concatenate 
multiple values together, return them via "return" and then split them up into 
separate values using "parse" in the invoker, but why should one have too?). 
The REXX designers missed a trick there -- all of the parameters should have 
been passed by reference on "use arg".  Then, if I wanted a mixture of "by 
reference" and "by value", I could have coded this:

  parse arg pattern , . , options  /* passed by value */
  use arg . , files. , .   /* passed by reference */

-- from CyberSimian in the UK

On Tue, 22 Feb 2011 10:16:45 -0000, "CyberSimian"
<CyberSimian3@BeeTeeInternet.com> wrote:

>Won't the "use arg" instruction do what you want?

You are perfectly correct - it won't. :-)

SysFileTree expects the NAME of the stem variable to be passed to it,
not the stem variable object itself.

In your example, you would pass it "FILES.", not files.

Maybe the SysFileTree in newer REXx's will accept a stem variable
object in place of the literal string for its' second argument, but
that would not really help me, as all of my code is passing the
literal string, and I would like not to have to change that; it would
be too risky.

It's one thing changing "SysFileTree" to "FileTree" across hundreds of
programs, but a much larger task changing "FILES." to *files.*

I might even have specifies the name of the stem variable in a
variable:

Stem = 'FILES.'
Call SysFileTree '*',stem,'FO'

.... but if I have done that, will someone please come and put me out
of my misery! 

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

CyberSimian wrote:
> Swifty wrote:
>> A typical call to SysFileTree might be something like:
>>     Call SysFileTree '*','F.','FO'
>> I'm wondering if it would be possible to emulate this in an external
>> REXX routine. The hard part would be passing that 'F.' as the name of
>> the stem *in the callers variable pool* that would be used for the
>> results.
> 
> Won't the "use arg" instruction do what you want?  Untested:
> 
> invoker:
>   files.0=0
>   call FileTree "*" , files. , 'FO'
> 
> In an external file:
> 
>   FileTree: procedure
>     use arg pattern , files. , options
>     /* "pattern" and "options" are passed by value */
>     /* "files." is passed by reference */
>     call SysFileTree pattern , files. , options
>     return
> 
> Aside: it has always struck me as inconsistent that only stem variables are 
> passed by reference on "use arg"; simple variables are still passed by value, 
> thereby precluding the ability elegantly to update multiple simple variables 
> in the invoker (emphasis on "elegantly" here; of course one can concatenate 
> multiple values together, return them via "return" and then split them up into 
> separate values using "parse" in the invoker, but why should one have too?). 
> The REXX designers missed a trick there -- all of the parameters should have 
> been passed by reference on "use arg".  Then, if I wanted a mixture of "by 
> reference" and "by value", I could have coded this:
> 
>   parse arg pattern , . , options  /* passed by value */
>   use arg . , files. , .   /* passed by reference */
> 
> -- from CyberSimian in the UK
> 
> 
I presume you want to do this to overcome the BUG that returns NON-FILE 
information on *nix boxes? The argument that 'everything is a file on *nix'
is specious, so you have a legitimate bug to report. That, however, doesn't 
solve your problem. I think the solution will involve INTERPRET, so I'll send 
you my dumpvars.rex in the hope that you can get something out of it.

-- 

Les               (Change Arabic to Roman to email me)

Swifty wrote:
> all of my code is passing the
> literal string, and I would like not to have to change that; it would
> be too risky.

Agreed -- especially on your production system.

> It's one thing changing "SysFileTree" to "FileTree" across hundreds of
> programs, but a much larger task changing "FILES." to *files.*
> I might even have specified the name of the stem variable in a
> variable:
> Stem = 'FILES.'
> Call SysFileTree '*',stem,'FO'

The following solution addresses these issues.  It does not require any
complicated parsing of quoted strings, and can be easily applied to all of the
REXX programs that call SysFileTree.  I have included a working example at the
end.  In summary, you do this:

(1)  Create a separate REXX file called (say) FileTree to perform the
invocation of SysFileTree (see below for example).

(2)  Use the append syntax of the COPY command to append the following lines
to each REXX file that calls SysFileTree (other than FileTree of course!):

; return
sysfiletree:
  parse arg pattern, stemname, options
  stmt='call filetree pattern, 'stemname', options'
  interpret stmt
  return

Explanation:
(a)  The appended lines begin with a semicolon. This is to handle the case
where the last line of the REXX file does not end with a proper line-end
sequence (carriage return+line feed on Windows).

(b)  The next token is "return".  This is to handle the case where there is no
explicit "return" or "exit" in the REXX program.  Normally, encountering the
end-of-file during execution is an implied return, but that will not longer
work with the extra lines present.

(c)  The name of the internal procedure is SysFileTree.  The REXX rule is that
internal procedures take precedence over built-in functions (such as left()
and strip()), and precedence over external interpreter-provided functions
(such as SysFileTree).  So the internal function is invoked in preference to
the external function.

(d)  The "procedure" keyword is NOT used.  The internal procedure must use the
same scope for variables as its invoker, otherwise the stem cannot be returned
with updated values.

The working example is shown below.

-- from CyberSimian in the UK

------------------ cut here -------------------
/* TREETEST.REX */
/* invoke as:   treetest [file_pattern]  */
  say 'TREETEST: Invoked.'
  parse arg pattern
  pattern=strip(pattern)
  if left(pattern,1)=='"'
  then parse var pattern '"' pattern '"' .
  else parse var pattern pattern .
  if pattern='' then
    pattern='*'
  options='FO'
  files.0=0
  call sysfiletree pattern, 'files.', options
  say 'TREETEST: 'files.0' files found.'
  do i=1 to files.0
    say 'TREETEST: 'files.i
  end i
  return

/* start of lines to be appended to each file that calls SysFileTree */
; return
sysfiletree:
  parse arg pattern, stemname, options
  say 'TREETEST: pattern==>'pattern'<=='
  say 'TREETEST: stemname==>'stemname'<=='
  say 'TREETEST: options==>'options'<=='
  stmt='call filetree pattern, 'stemname', options'
  say 'TREETEST: stmt==>'stmt'<=='
  interpret stmt
  return
--------------------- cut here -----------------
/* FILETREE.REX */
  say 'FILETREE: Invoked.'
  use arg pattern, files., options
  call sysfiletree pattern, 'files.', options
  say 'FILETREE: 'files.0' files found.'
  return
-------------------- cut here ------------------
E:\store\o\oorexx\test>treetest
TREETEST: Invoked.
TREETEST: pattern==>*<==
TREETEST: stemname==>files.<==
TREETEST: options==>FO<==
TREETEST: stmt==>call filetree pattern, files., options<==
FILETREE: Invoked.
FILETREE: 5 files found.
TREETEST: 5 files found.
TREETEST: E:\store\o\oorexx\test\filetree.rex
TREETEST: E:\store\o\oorexx\test\tree.rex
TREETEST: E:\store\o\oorexx\test\treetest.rex
TREETEST: E:\store\o\oorexx\test\treetest1.rex
TREETEST: E:\store\o\oorexx\test\usearg.rex
E:\store\o\oorexx\test>
----------------------------------------------- 

On 02/23/2011 01:53 PM, CyberSimian wrote:
> (2)  Use the append syntax of the COPY command to append the following lines
> to each REXX file that calls SysFileTree (other than FileTree of course!):

--which defeats the purpose of putting FileTree in an external library
in the first place.  If the appended code ever needs fixing, it'll now
have to be fixed in a zillion places rather than just one.  And it does:

> ; return

That should be EXIT, not RETURN--if the original program ends in the
middle of a subroutine, you don't want to send control back to the
calling routine.

>   parse arg pattern, stemname, options
>   stmt='call filetree pattern, 'stemname', options'
>   interpret stmt

Woe is you if the program already uses any variables by those names.
It's just as simple to do it without using any variables, though.

>   return

Just in case FileTree is ever updated to return a value, you should
return its result.  So the whole thing becomes:

  ; Exit
  SysFileTree:
    Interpret 'Call filetree Arg(1),' Arg(2)', Arg(3)'
    Return Result

However, you can't just copy this to the end of an Object Rexx program.
 It has to come before the first directive if there are any.

�R

On Feb 22, 12:38=A0pm, LesK <5mr...@tampabay.rr.com> wrote:

> I presume you want to do this to overcome the BUG that returns NON-FILE
> information on *nix boxes?

Well, the code is doing exactly what it was designed to do:

  if(S_ISREG(finfo->st_mode) ||        /* if it is a file
*/
     S_ISCHR(finfo->st_mode) ||        /* or a device special
*/
     S_ISBLK(finfo->st_mode) ||        /* file
*/
     S_ISSOCK(finfo->st_mode) ||       /* or a socket
*/
     S_ISLNK(finfo->st_mode) ||        /* or a symbolic link
*/
     S_ISFIFO(finfo->st_mode)){        /* or a FIFO
*/

So, the code was specifically designed to find symbolic links.  That's
not a bug, it's a design decision.

--
Mark Miesfeld

Mark Miesfeld wrote:
> On Feb 22, 12:38 pm, LesK <5mr...@tampabay.rr.com> wrote:
> 
>> I presume you want to do this to overcome the BUG that returns NON-FILE
>> information on *nix boxes?
> 
> Well, the code is doing exactly what it was designed to do:
> 
>   if(S_ISREG(finfo->st_mode) ||        /* if it is a file
> */
>      S_ISCHR(finfo->st_mode) ||        /* or a device special
> */
>      S_ISBLK(finfo->st_mode) ||        /* file
> */
>      S_ISSOCK(finfo->st_mode) ||       /* or a socket
> */
>      S_ISLNK(finfo->st_mode) ||        /* or a symbolic link
> */
>      S_ISFIFO(finfo->st_mode)){        /* or a FIFO
> */
> 
> So, the code was specifically designed to find symbolic links.  That's
> not a bug, it's a design decision.
> 
> --
> Mark Miesfeld

Well, I don't have the Requirements or Design documents so I have to assume that 
the ooRexx Reference properly reflects both of them. It clearly states that the 
F option means "Search only for files" and the comment in the code shows when a 
'file' is detected. Everything else should be triggered by some other option.
I conclude that it's a Quality bug, in that it doesn't "Conform To Requirements".

-- 

Les               (Change Arabic to Roman to email me)

On Feb 24, 4:55=A0am, LesK <5mr...@tampabay.rr.com> wrote:
> Mark Miesfeld wrote:
> > On Feb 22, 12:38 pm, LesK <5mr...@tampabay.rr.com> wrote:
>
> >> I presume you want to do this to overcome the BUG that returns NON-FIL=
E
> >> information on *nix boxes?
>
> > Well, the code is doing exactly what it was designed to do:
>
> > =A0 if(S_ISREG(finfo->st_mode) || =A0 =A0 =A0 =A0/* if it is a file
> > */
> > =A0 =A0 =A0S_ISCHR(finfo->st_mode) || =A0 =A0 =A0 =A0/* or a device spe=
cial
> > */
> > =A0 =A0 =A0S_ISBLK(finfo->st_mode) || =A0 =A0 =A0 =A0/* file
> > */
> > =A0 =A0 =A0S_ISSOCK(finfo->st_mode) || =A0 =A0 =A0 /* or a socket
> > */
> > =A0 =A0 =A0S_ISLNK(finfo->st_mode) || =A0 =A0 =A0 =A0/* or a symbolic l=
ink
> > */
> > =A0 =A0 =A0S_ISFIFO(finfo->st_mode)){ =A0 =A0 =A0 =A0/* or a FIFO
> > */
>
> > So, the code was specifically designed to find symbolic links. =A0That'=
s
> > not a bug, it's a design decision.
>
> > --
> > Mark Miesfeld
>
> Well, I don't have the Requirements or Design documents so I have to assu=
me that
> the ooRexx Reference properly reflects both of them. It clearly states th=
at the
> F option means "Search only for files" and the comment in the code shows =
when a
> 'file' is detected. Everything else should be triggered by some other opt=
ion.
> I conclude that it's a Quality bug, in that it doesn't "Conform To Requir=
ements".
>
> --
>
> Les =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Change Arabic to Roman to email me)

I think we come down to semantics in the end.  When is a file not a
file, when is a bug not a bug.  I assume rexxUtil was designed in a
simpler world where files either had the directory attribute set or
did not.

I'm not a linux user myself, but I imagine that the status quo does
"Conform To Requirements" for many, and changing the status of a
symbolic link from a 'file' to a 'directory' would break code.

I think a constructive way forward would be to put in a RFE.
In it you might request another option which added the exact nature of
the entity found to the output.

On Wed, 23 Feb 2011 22:26:11 -0800 (PST), Sahananda
<sahananda@gmail.com> wrote:

>I'm not a linux user myself, but I imagine that the status quo does
>"Conform To Requirements" for many, and changing the status of a
>symbolic link from a 'file' to a 'directory' would break code.

I'm a linux user insofar as I know how to logon, and how to get myself
into a pickle shortly afterwards. What follows is my views.

A symbolic link is neither a file nor a directory, it is a pointer to
something else. The something else may be a file, or a directory or
something else again (there are other classes, for example "device").

SysFileTree deals only in files and directories, so symbolic links
cause problems. They are neither file nor directory, so perhaps should
be excluded altogether. But when a symbolic link points to a file,
then for all intents and purposes it behaves as a file. Likewise a
link pointing to a directory behaves as a directory.

For my purposes, where I want to deal only with things that behave as
files, a symbolic link which points to a file is of interest, while a
symbolic link which points to directory is of no interest.

The original specification of the REXX language specified that a "high
astonishment factor" was undesirable. I asked for files, and one of
the results was an object that was indistinguishable from a directory
(I had used the "FO" options, so had only the name, and the fact it
was in the results to go on. I was astonished.

Someone else might be astonished that a list of files did NOT include
a symbolic link (which is itself, actually, a file) just because it
pointed at a directory. 

A parallel is the handling of null values in databases. If a value is
null, then it will not appear in a list based on the selection "where
value = 1" but then neither will it appear in the list "where value \=
1" either. So it is neither equal to 1 nor different from 1.

We could have hours of fun discussing this.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

Swifty wrote:
> On Wed, 23 Feb 2011 22:26:11 -0800 (PST), Sahananda
> <sahananda@gmail.com> wrote:
> 
>> I'm not a linux user myself, but I imagine that the status quo does
>> "Conform To Requirements" for many, and changing the status of a
>> symbolic link from a 'file' to a 'directory' would break code.
> 
> I'm a linux user insofar as I know how to logon, and how to get myself
> into a pickle shortly afterwards. What follows is my views.
> 
> A symbolic link is neither a file nor a directory, it is a pointer to
> something else. The something else may be a file, or a directory or
> something else again (there are other classes, for example "device").
> 
> SysFileTree deals only in files and directories, so symbolic links
> cause problems. They are neither file nor directory, so perhaps should
> be excluded altogether. But when a symbolic link points to a file,
> then for all intents and purposes it behaves as a file. Likewise a
> link pointing to a directory behaves as a directory.
> 
> For my purposes, where I want to deal only with things that behave as
> files, a symbolic link which points to a file is of interest, while a
> symbolic link which points to directory is of no interest.
> 
> The original specification of the REXX language specified that a "high
> astonishment factor" was undesirable. I asked for files, and one of
> the results was an object that was indistinguishable from a directory
> (I had used the "FO" options, so had only the name, and the fact it
> was in the results to go on. I was astonished.
> 
> Someone else might be astonished that a list of files did NOT include
> a symbolic link (which is itself, actually, a file) just because it
> pointed at a directory. 
> 
> A parallel is the handling of null values in databases. If a value is
> null, then it will not appear in a list based on the selection "where
> value = 1" but then neither will it appear in the list "where value \=
> 1" either. So it is neither equal to 1 nor different from 1.
> 
> We could have hours of fun discussing this.
> 
Did OS/2 have symbolic links and all that other stuff that the code checks for? 
If not, then the code matched the Ref back then and any code added afterwards 
introduced a bug. Since ooRexx is based on ORexx, it inherited the bug in either 
the code or the documentation.  I respectfully submit that one or the other 
should be fixed.

-- 

Les               (Change Arabic to Roman to email me)

On Thu, 24 Feb 2011 10:16:05 -0500, LesK <5mre20@tampabay.rr.com>
wrote:

>Did OS/2 have symbolic links and all that other stuff that the code checks for

That's pushing the outer limits of my memory! 

I believe the HPFS had hard links, and there were things like symbolic
links which I vaguely  remember as things that you put on the desktop
to launch a program. These were part of the Workplace Shell. 

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

Swifty <steve.j.swift@gmail.com> wrote:

> A parallel is the handling of null values in databases.

Do you mean a value of "", or no value at all?

Surely if a particular database architecture allows a value not to be
present then every query/transaction has to be defined carefully to take
that into account?

> If a value is null, then it will not appear in a list based on the
> selection "where value = 1" but then neither will it appear in the list
> "where value \= 1" either.

But that's sloppy terminology. You need to distinguish between 

                            (ispresent(value) & value \= 1)

or:     \ispresent(value) | (ispresent(value) & value \= 1)
  

-- 
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".  

On Thu, 24 Feb 2011 16:15:28 UTC, Swifty <steve.j.swift@gmail.com> 
wrote:

> On Thu, 24 Feb 2011 10:16:05 -0500, LesK <5mre20@tampabay.rr.com>
> wrote:
> 
> >Did OS/2 have symbolic links and all that other stuff that the code checks for
> 
> That's pushing the outer limits of my memory! 
> 
> I believe the HPFS had hard links, and there were things like symbolic
> links which I vaguely  remember as things that you put on the desktop
> to launch a program. These were part of the Workplace Shell. 

No it didn't. What you recall are shadows and what Win calls 
shortcuts. They were pointers to objects that only worked with 
Workplace Shell aware apps. So command line stuff could not see them. 
True symlinks have been added, via the gcc compiler port, but only 
stuff compiled with the support can see them. Everything else sees 
them as files. The file system does sort of support owner/group/perms 
but only in so far as it does not barf on say an unzip that has them. 
They don't actually do anything in *nix terms. The OS/2 NFS port gets 
completely buggered when pointed at a *nix file system that has links 
in it. 

-- 
Regards
Dave Saville

On Thu, 24 Feb 2011 16:22:49 +0000, Jeremy Nicoll - news posts
<jn.nntp.scrap007@wingsandbeaks.org.uk> wrote:

>Do you mean a value of "", or no value at all?

I'm only certain of my ground in DB2, and even there, "certain" is a
relative term. :-)

A "cell" in a DB2 table can sometimes be set to the value Null. Not
"Null" (a four-letter word) nor is it a zero length character string.
It is null,  which typically means "Unknowable". So null is never
equal to anything (not even null) neither is it not equal to anything
(including null). It is probably not even equal to itself.

So yes, you have to be very wary of nulls. If you select "where value
!= 1" then you would expect to get all the rows that do not contain 1,
but you won't get the rows where it is null.

So you have to select "where value !=1 or value is null". This turns
up whenever you want to "set to 1 anything which is not 1".

I dislike this with a passion, as I fall into this trap at every
opportunity for it happening. 

I tried suggesting an "is (not) identical" comparison operator,
suggesting REXx's == but I got rebuffed. I'm the only person in the
world who sees the value of this, apparently, and others queued up to
lambaste me. 
See: http://www.swiftys.org.uk/wiz?630

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

Swifty <steve.j.swift@gmail.com> wrote:

> So you have to select "where value !=1 or value is null". This turns
> up whenever you want to "set to 1 anything which is not 1".
> 
> I dislike this with a passion, as I fall into this trap at every
> opportunity for it happening. 
> 
> I tried suggesting an "is (not) identical" comparison operator,
> suggesting REXx's == but I got rebuffed. I'm the only person in the
> world who sees the value of this, apparently, and others queued up to
> lambaste me.
 
> See: http://www.swiftys.org.uk/wiz?630

Ah, an unbiased webmaster agrees with you!

I think my view would be to agree with you, if - and only if - the query
language did not support any way of identifying the situation.  But you say
that 

  'value is null'

can be coded... so there is a way to check. 

I'd have thought that a more sensible approach is to wonder why, in a
specific instance, a database's designers chose to allow null values in a
cell in the first place.  If they did that consciously for an intended
reason, then it's fair enough that a db does have them. 

-- 
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".  

On 02/25/2011 02:51 AM, Swifty wrote:
> It is null,  which typically means "Unknowable". So null is never
> equal to anything (not even null) neither is it not equal to anything
....
> So you have to select "where value !=1 or value is null".

Can't you just negate the condition?  "where not (value = 1)"

�R

In <5m0dm69ufhcou0h9nmi9so8locsgkgopc3@4ax.com>, on 02/24/2011
   at 04:15 PM, Swifty <steve.j.swift@gmail.com> said:

>I believe the HPFS had hard links, and there were things like
>symbolic links which I vaguely  remember as things that you put on
>the desktop to launch a program. These were part of the Workplace
>Shell. 

The WPS has shadow objects, which provide an alias for some other
object[1]. The WPS also has program objects, which are not the same as
shadows. A program object not only specifies the path to the
application but provides options as to how to run it, e.g.,
parameters, session type.

I'm not aware an alias facilities in any OS/2 file system.

[1] Not necessarily a file or directory.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org