printer file "name" - problem

[Brian K. White]

----- Original Message ----- 
From: "Dennis Malen" <dmalen at malen.com>
To: "Brian K. White" <brian at aljex.com>; "filePro mailing list" 
<filepro-list at seaslug.org>
Sent: Thursday, March 17, 2005 2:39 PM
Subject: Re: printer file "name" - problem


> Brian,
>
> I reviewed your comments and I find that my processing has everything you 
> suggested except for :
>
> system noredraw "umask 0;>"<fn
>
> Is this line necessary and why?

It creates the file with open permissions, at a point before fp tries to, 
rather than allow fp to create the file.
If fp creates the file, then other processes will not have permission to 
work with the file.
It also zero's out the file if it already exists. It also does not modify 
the files perms if it already exists, so if the exact filename hasn't 
changed from previous attempts at doing this, you should delete the file so 
that this command will create it anew.

when I say "fp creates the file" I mean any of the various way that clerk or 
report can create a file directly that don't allow you to specify what 
ownerships or permissions the created file will have.
thsi would include the -p flag, the "printer file" command, the export 
command, the open command, and probably others I am noth thinking of or just 
never use, like the html commands

It's OK to let fp create files with those comands if you are only going to 
use fp to work with them. That is, you won't need to manipulate them with 
system commands or completely outside processes like cron jobs that do ftp's 
or cgi scripts etc... If you use the open command to create a file, then you 
can always use the remove command to delete it. But you cannot use system rm 
filename unless you happen to be logged in as either root or filepro. If a 
user runs a process that allows fp to create a file, then system commands 
get run as the user, who is not filepro or root, and therefore has only 
limited permission to access that file. Maybe they can read it, but they 
can't move/rename or delete it.

Since fp provides no way to specify what permissions files get created with 
except for one command I never use JS? HTML?, then the only way to get the 
file created with specific permissions you desire, is to create the files 
yourself some other way before ever referencing them in fp.

You can do that before calling report, or you can do it in a system command 
as long as it comes before any printer file commands.

The system comand above is just the shortest way to create a file with 
rw-rw-rw- permissions.
It's equivalent but slightly less typing and I think slightly less cpu and 
disk i/o than saying:
">filename ; chmod 666 filename"



> I still need the PUTENV, as I only want the heading to be printed once. I 
> am

putenv has no effect in the place where you have it.

If you want that variable to affect rreport, then you have to set it in the 
environment _before_ rreport even starts up.
By the time you hit that processing, even if it's before the first record, 
it's already too late for it to have any effect on the instance of rreport 
you are running in.

clerk & report only "look" at their environment one time when they are first 
starting up, way before even thinking about running any processing or 
reading or even selecting the first record.
That's why that putenv has no effect. This is not to say the putenv comand 
does nothing and is therefor a meaningless command.
If you do a putenv pfonehead, and then do a system rreport blah... , the 
rreport in that system command will have pfonehead in it's environment and 
it will affect the behaviour of that rreport.


> only executing that command once, unless it doesn't matter. I do know that 
> PRINTER FILE (per Ken) must only be executed once. I'm not clear on 
> whether PRINTER TYPE needs to be only once. If someone would clarify that, 
> it would be appreciated.
> Once I get this clarified I will post the final results on what works. It 
> is evident that this is not clear to everyone. This is what the list is 
> all about.

I don't know if it's harmful to run it every record. I do know it's 
unecessary.
It may hurt by sending the init codes more than once, Then again, in this 
case you may not see the problem even if it did exist, because "nocodes" 
just happens to not have any init code, or maybe that's what's zero-ing out 
the file.

My guess is that if it's still not working then it's because of somethin you 
haven't shown us yet, like other processing, or the other commands in the 
script that runs this, or other details about the environment at the time 
the report runs.

If it were me, I'd put a show @  or msgbox statement just after the printer 
file commands, and at the beginning or end of the main report body (the part 
that runs for every record) and maybe in @done too, and then in another 
window I would delete the output file if it exists, verify the directory 
where the files will go is rwxrwxrwx (/tmp is), and evey time the show 
statement halts the processing, look at the directory for the output file. 
what are it's permissions?, read it with cat/pg/less to see what it's 
contents are at various stages. Maybe data is written and then blown away at 
the next record? Maybe it exists and is good, but has permissions such that 
the system command doesn't have permission to even read it?

And since you sound like you didn't actually try what I posted, one thing I 
don't see in yours is, Is "pa" defined with ,g ???


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