issue with USER... need help.

[Brian K. White]

On 3/1/2013 11:37 AM, Richard D. Williams wrote:
> On 5/22/2012 6:49 AM, Kenneth Brody wrote:
>> On 5/22/2012 1:18 AM, Fairlight wrote:
>>> I used to use USER a long time ago.  It's not that complex.  I'm running
>>> into an issue on a SCO OSR5 box, though.  I'm hitting the same issue with
>>> fP 4.8 and 5.0.x, so if anything I'm suspecting the environment somehow.
>>> But here's the code:
>>>
>>> @wef1::user flprog="/bin/cat /etc/group":
>> [...]
>>> This is -really- drop dead simple, and I can't figure out why it'd acting
>>> all fritzy on me.  Someone please give me some idea why it's acting like
>>> this?
>> [...]
>>
>> Remove the quotes:
>>
>>        user flprog = /bin/cat /etc/group
>>
> I am having an issue with "user" as well.
> Can you pass arguments?   user flprog = /usr/local/bin comp_passwd var1 var2
>
> var1 and var 2 would be in my processing table.
>
> I am using a script to make passwords case sensitive and I need to pass
> the entered filed value to the stored field value.

User is petty tricky to use. It's easy to invoke, it's just tricky to 
avoid problems getting out of sync with the user process and problems of 
many zombie copies of the user process building up in the background, 
consuming all available process slots in extreme cases.

The docs for user() should really have a page or more devoted to a 
reference best practices template for how to wrap it in a gosub that 
does the right thing and the rest of your table does ALL work via that 
gosub, never directly referencing the alias.

You often may want a wrapper shell script around the actual program 
also, because you can make sure the shell script behaves predictably 
even though you can't always make the program you want behave 100% 
predictably. The shell allows you to handle some cases that you can't 
handle in filepro directly because of the strict way user behaves. in 
filepro you have to know for certain when the program is going to write 
something and when it expects to read something. For example in the 
shell you can run a program and capture it's output and then look at 
that output, and it doesn't matter if the program output 5 lines, output 
1 line, output 0 lines, or crashed. You can also test the exit value of 
the program you ran to tell the difference between empty output that was 
intentional vs empty output because it crashed or you fed it bad input 
that it rejected.

But in filepro with user, if you run a command and try to read a line of 
output the the program didn't output, you'll hang there forever. You 
have to BREAK out. It won't time out and it won't just return an empty 
string like the shell would, it hangs until the program produces something.

Basically, user is usually the wrong tool except for very specific 
situations where you have to talk back and forth with a program in 
several steps or when you are going to use a program many times over.

Usually its far easier and more reliable to use system() and temp files.
Let the OS worry about the efficiency. The OS magics away the actual 
disk writes all in the disk cache anyways when you are 
writing/reading/deleting all at once in a small time anyways. Also many 
systems use a ramdisk for /tmp now anyways. There is still filesystem 
overhead creating and deleting files even though they don't actually 
have to wait for a physical disk, so it's not technically 100% magicked 
away, but quite a lot.

-- 
bkw