printer file "name" - problem RESOLVED!!!!!

[Brian K. White]

----- Original Message ----- 
From: "Dennis Malen" <dmalen at malen.com>
To: "Kenneth Brody" <kenbrody at bestweb.net>
Cc: <filepro-list at lists.celestial.com>
Sent: Friday, March 18, 2005 5:45 PM
Subject: Re: printer file "name" - problem RESOLVED!!!!!


> Ken,
>
> The only thing I can think of is that when I defined nocodes as a printer 
> in filePro that I did not include a destination file. I'm not sure. The 
> processing did not work so I asked the list to comment.
>
> After going back and forth with the list for a couple of days I may have 
> added the destination file in the printer definition of  "nocodes". I'm 
> not sure, as so many people on the list had different ideas of what should 
> work or should not work. I'm not sure when I changed it.
>
> The more important point is there was a diverse opinion on how the 
> processing should work and a number of people were confused. I wanted to 
> make sure that I clarified the issues I raised and published something 
> that I know works. If anyone had a diiferent approach then I requested 
> they share it with us.

Well I'll be slapped.

I got so annoyed by this that I went through the bother of testing it 
explicitly with a new report in a small file with messageboxes inserted at 
the top & bottom of all three main sections of processing, (main body, 
@once, @done) and verified that PFONEHEAD was not in the environment nor in 
the config file, and had the putenv commented out of the report, and had the 
report defined with a page length only long enough to fit the header and one 
record, so it would have to make a header for every record. Then set up a 
loop in another window that just did a clear screen and then ls and a cat of 
the output file once every second, then ran the report in the first window 
and watch the file appear, noted its permissions & ownership and watched 
it's contents grow record at a time as I slowly hit enter to step through 
the messageboxes in the report.

Exactly as I expected, the file got created with rw-r--r-- permissions, 
owned by "filepro", and I got one header for every record.

I then deleted the file, uncommented the putenv, started the monitor loop 
again, started the report again, and very much contrary to expected, I only 
got one header!

Also, along the way I determined that rreport respects the umask that was in 
place at the time you started rreport. That is, the default umask is 022, 
which results in most any commands creating files with the permissions shown 
above, just as rreport did the first time. However, if you set umask 0 
before even running rreport, then when rreport creates files it creates them 
rw-rw-rw-, which is really just as it should be and just like all other 
commands behave. Don't know why I never noticed that before but now that I 
see it I realise it shouldn't exactly be surprising.

Just for the record, I'm not crazy or inventing or lying.

Quoting Ken (& myself):

-----snip-----
"Brian K. White" wrote:
>
> ----- Original Message -----
> From: "Kenneth Brody" <kenbrody at bestweb.net>
[...]
> > GETENV() will return the value of the variable at the time you execute
> > the function.
[...]
> ...splutter...gurgle...but but but,
> I thought _you said_ a while back that it only scanned once ??!!
>
> of course I beleive you if you say so, but I will have to dig through old
> emails now, because I know I did not arrive at the above
> (mis)understanding on my own or out of thin air. You must have said
> something similar that has since been muddied up a bit thanks to analog
> memory.

You are probably thinking of specific variables, used internally by
filePro, which filePro reads only the first time.  For example, doing
PUTENV "TEXTNORMAL" will not cause filePro to change colors.  But, if
you did such a thing, GETENV("TEXTNORMAL") would return the updated
value.

-- 

+---------+----------------------------------+-----------------------------+
| Kenneth |     kenbrody at spamcop.net      | "The opinions expressed     |
|    J.   |                                  |  herein are not necessarily |
|  Brody  |    http://www.hvcomputer.com     |  those of fP Technologies." |
+---------+----------------------------------+-----------------------------+
GCS (ver 3.12) d- s+++: a C++$(+++) ULAVHSC^++++$ P+>+++ L+(++) E-(---)
    W++ N+ o+ K(---) w@ M@ V- PS++(+) PE@ Y+ PGP-(+) t+ R@ tv+() b+
    DI+(++++) D---() G e* h---- r+++ y?

-----snip-----

Doesn't "PFONEHEAD" fall squarely in this category.
Isn't it actually a bug that it does what Dennis and I just showed?

I don't think it matters too much to me if it works this way or the way I 
thought and you said, so I'm not really saying one way is correct and one 
way is wrong.
But I CAN'T live with the behaviour changing back and forth nor can I live 
with not knowing which variables behave one way and which ones behave a 
different way.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani