System "wget"command

[Kenneth Brody]

Quoting Mike Schwartz (Tue, 15 May 2007 07:57:00 -0500):

>      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

Question of style:  Why use chr("39") rather than an apostrophe?

Note on your posting:  This is obviously not a cut-and-paste, as the
code itsn't valid.  (It's missing some quotes.)  Can you post the
actual code?

>      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

So you're getting the actual command line, not wget's output, sent to
the screen?  Does the command execute on these instances?

>      I've tried "system noredraw SA" without any noticible difference.

I would expect not.  SYSTEM NOREDRAW explicitly tells filePro "leave
whatever output is generated (if any) on the screen".  Typically, this
is used when you know that the SYSTEM command won't send anything to
the screen, and you want to avoid the screen "blinking" because of the
clear-plus-redraw upon return.

SYSTEM by itself will force a screen clear and redraw upon return.

When the text appears on the screen, do you notice that it appears
after filePro redraws the screen upon return?

[...]
>      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."

Does pressing Ctrl-L redraw the screen properly?  If so, you may be
able to force (another) redraw using PUSHKEY "[DRAW]".  However, as
filePro has already cleared and redrawn the screen, this should be
a no-op.  (Well, aside from the visual "blink" for the second redraw.)

[...]
>     I've also tried to push a Unix "screen redraw" command,

What's a "Unix 'screen redraw' command"?

[...]
>     Would it make any difference if I got this working with the filePro
> "USER" command, rather than the "SYSTEM" command?

No idea.  Given that there is no reason for this to be appearing on
the screen in the first place, I can't say what would stop it from
appearing.

When it happens again, can you grab an actual, full screenshot and post
it here?  (You can replace any sensitive data with "X"s if you prefer,
but leave everything else alone.)

Is there any possibility that the command you are executing actually
ends with a "&" to run the command in background?  Some shells echo
the command line when a background task finishes.

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com