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

[Dennis Malen]

Brian,

That's the beauty of the list. We all learn something along the way.

Dennis

----- Original Message ----- 
From: "Brian K. White" <brian at aljex.com>
To: "filePro mailing list" <filepro-list at seaslug.org>
Sent: Friday, March 18, 2005 10:58 PM
Subject: Re: printer file "name" - problem RESOLVED!!!!!


>
> ----- 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
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>