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

[Brian K. White]

----- Original Message ----- 
From: "John Esak" <john at valar.com>
To: "Fplist (E-mail)" <filepro-list at seaslug.org>
Sent: Tuesday, March 22, 2005 1:22 AM
Subject: RE: printer file "name" - problem RESOLVED!!!!!


>
>>
>> >
>> > Dennis,
>> >
>> > I have completely avoided this thread... it just seemed to be going on
>> > pretty well between you and Ken... or others... I ignored.
>> Today I caught
>> > one question from either you or Brian (it was apparently from Brian, 
>> > but
>> > looked to be from you.. the whole message was unquoted...)  Anyway, no
>> > matter. It mentioned Ken saying that using PUTENV and filePro variables
>> > would not affect the current running process...
>> >
>> > Okay, first off... PUTENV works entirely... correctly, and
>> completely. At
>> > least it has for me for many years... I rely on it heavily, daily in
>> > almost
>> > everything I write. I think you should have no qualms about using it 
>> > and
>> > GETENV.  What Ken was probably talking about (and I can only
>> guess because
>> > I
>> > didn't see his words...) was that you can not use PUTENV with
>> the filePro
>> > PATH variables, i.e., PFDIR, PFDATA and PFPROG... to change the
>> > environment
>> > of the "current" process.  Doesn't that sound reasonable. As
>> for all other
>> > variables (maybe excepting PFDSK??) I don't see any problem.
>> >
>> > Of course, this is just a guess about what you are asking about.
>> >
>> > John
>>
>> You don't know what you're talking about.
>> Read the saved emails and/or refrain from deleting mails from threads you
>> ever intend to join.
>> I was very clear a couple of times already so I don't see the point in
>> repeating myself because you were ignoring the thread.
>>
>> Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
>
> You've just proven it once and for all Brian... you truly are the asshole
> you most usually appear to be. Anywone reading my message above and your
> completely unwarranted response can see it for
> themselves. In future I will not see any of your crap, period. :-)

OK so I'm an asshole.
How does this address the point that you don't know what you are talking 
about?
Not a single point above has anything to do with the thread you ignored and 
then tried to weigh in on after having ignored.

But let's pretend for a moment your oh so obviously omnipotent observations 
had anything to do with the discussion at hand.

>> > Okay, first off... PUTENV works entirely... correctly, and
>> completely. At

Define "putenv works". I use putenv all the time and would resolutely agree, 
of course it works. I never said it didn't
Expecting putenv to alter the behaviour of a program that has already loaded 
up and already consulted it's environment for such variables is what I 
thought didn't work, and thought it shouldn't work, and if it does then I 
want it to work across the board and be a documented behaviour because it's 
not obvious or intuitive.

>> > didn't see his words...) was that you can not use PUTENV with
>> the filePro
>> > PATH variables, i.e., PFDIR, PFDATA and PFPROG... to change the
>> > environment
>> > of the "current" process.  Doesn't that sound reasonable. As
>> for all other
>> > variables (maybe excepting PFDSK??) I don't see any problem.

Of course path variables can't be set via putenv, right? Obviously, if the 
path variables aren't right, then how could you get to the point where you 
could set them via putenv?
Well, why not? If putenv pfonehead will alter the behaviour of a currently 
running instance of rreport, then why can't putenv pfconfig switch to some 
other config file? or pfdata switch to some other body of data? No absolute 
technical reason I can think of. It'd be hard to read/write/debug a program 
that does that much but so what? Even if we stipulate that if there are any 
open records or lookups you can't switch paths, or, maybe that the requested 
switch won't happen until the next available opportunity like when 
processing for the current record finishes. I can even imagine changing 
pfprog without hitting a logic train wreck and have it actually do something 
useful.

But in fact, neither of us ever mentioned path variables. We were talking 
about pfonehead, which I am no longer claiming doesn't work, in fact I 
proved that it does and described the experiment so as to remove all doubt, 
and I had quoted an old message that talked about textnormal, in which Ken 
stated clearly that changing the value will not cause fp to change it's 
display colors but it will show the new value if you getenv it.

It's all pretty simple and and if you joining a conversation and setting 
everyone straight without having bothered to even read the conversation up 
to that point makes me an asshole, so be it.
For my part, it would be easy and not unjustified to bounce the impressively 
professional "asshole" name back at you, but really I don't quite think 
that.
I think you just have the worst case of "can dish it out but can't take it" 
I've ever encountered.

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