System "wget"command

Brian K. White brian at aljex.com
Tue May 15 11:44:03 PDT 2007


----- Original Message ----- 
From: "Mike Schwartz" <mschw at athenet.net>
To: <filepro-list at lists.celestial.com>
Sent: Tuesday, May 15, 2007 8:57 AM
Subject: System "wget"command


>     On filePro 5.0.5, SCO Openserver 5.0.6, I'm trying to execute wget 
> with
> a "system" command.  The command executes correctly, but about once every
> 100 times it executes, the text of the wget call "splashes" across the
> screen, beginning at the current cursor position.  My code looks like:
>
> sa(300,*)="/usr/local/bin/wget -O /dev/null -w 4 -T 5 -t 1 -q" <chr("39")
> {http://192.169.0.12/cgi-bin/callback/new_cust.pl?code=" {1 {chr("39")
> <"1> /dev/null 2> /dev/null
>
> system sa
>
>     This code notifies an accounting server that one of the people on the
> sales server has just created a new account.
>
>     The "splashed" line across the screen is the full text of the WGET
> command, for example:
>
> /usr/local/bin/wget -O /dev/null -w4 -T 5 -t 1 -q 'http://192.169.0.12/
> cgi-bin/callback/new_cust.pl?code=M78982' 1> /dev/null 2> /dev/null
>
>     I've tried "system noredraw SA" without any noticible difference.  The
> only thing that seems to work is to clear the bottom half of the screen 
> with
>
> CLS("11","9")
>
>     Unfortunately, then I have to do a "display" and other manipulations 
> to
> redraw the bottom half of the screen. On a couple of the screens where 
> this
> is called, it takes a lot of code to keep redrawing the screens and the
> users don't like the "blinking" effect of redrawing the whole screen.
>
>     ALSO:  I don't recall how to force filePro to completely redraw a
> screen.  "Display" only redraws the data, but the field names and static
> graphics are still missing.  "SCREEN newcust" doesn't force a complete
> redraw, probably because filePro thinks, "hey!  I'm already on screen
> "newcust", so I don't really need to redraw it."
>
>    I have concocted a bunch of "PUSHKEY" steps that switch to a different
> screen, then switch them back to the original screen.
>
>    I've also tried to push a Unix "screen redraw" command, but that 
> doesn't
> always work correctly with Accuterm and a couple of the other terminal
> emulation packages.  (These users have a mix of terminal emulation 
> packages,
> so I don't want to depend on the Unix screen redraw function.)
>
>    Would it make any difference if I got this working with the filePro
> "USER" command, rather than the "SYSTEM" command?
>
> Thanks
>
> Mike Schwartz

best:
video off ; system sa ; video on

less good:
system sa ; video sync

even more kludgey but good to know for odd situations,
echo "\014\c" in the system command
   will require lots more backslashes, this is the way you'd type it in 
manually at the shell
   system command would be like:
   system "echo \\\014\\c\"   ...and of course my and probably your email 
clients are making it impossible to actually send the line of text I want. 
It just "ate" two of my quote marks and is displaying part of the line as if 
it were a url. Guess you just have to know how to escape things in a system 
command to arrive at a given desired result that the shell will see at run 
time.

also
system sa ; pushkey "[DRAW]"
and
system sa ; show raw chr("12")

video off ; system sa ; video on   should provide the cleanest experience 
for the user because instead of letting the screen get messy and then redraw 
it, it smply freezes the screen before it gets messy & while system runs so 
it never gets messed up, and doesn't need to be redrawn after.

I don't know if system noredraw makes a difference in this case. even if it 
doesn't make a visual difference, it might be slightly faster from skipping 
the redraw step, which is not the same as doing the redraw step but keeping 
the output from reaching the screen. May also be the case that fp is smart 
enough to automatically do noredraw if video is off at the time system is 
run, and so it doesn't matter whih way your write the command and so might 
as well leave noredraw off simply because it's shorter. That fine point 
would be a Ken question since the manual doesn't go into that level of 
detail.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!



More information about the Filepro-list mailing list