System "wget"command

[Mike Schwartz]

> 
> > On Tue, May 15, 2007 at 02:44:03PM -0400, Brian K. White wrote:
> >> > /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
> >
> > Oops.  Missed that you'd said this.
> >
> > Never mind
> 
> I dunno. We use system commands an awful lot, including wget specifically,
> and also including large multiline commands built up into one variable,
> Way more than enough that if it were doing something messy one out of
> every
> 100 times our phones would kill us.
> and we never see this.
> 
> I suspet we don't have the full picture here. Something like shell
> globbing
> only occasionally finding a filename match and expending itself, thsu
> causing either the filename or an error message to appear where normally
> nothing does. Or the sa variable being shown (on a screen, a command in
> auto...) or the sa variable no being rigorously zero'ed out and/or handled
> to keep any leading/trailing junk trimmed.
> 
> given the command has -O /dev/null, and -q, and 1>/dev/null, and
> 2>/dev/null
> it must either be a failure in the shell itself, or in filepro's system(),
> or there is something we don't know yet.
> 
> only because I use system a lot myself on sco and linux just this same
> way,
> I don't suspect filepro or the shell.
> 
> If it were me I would now make up a dummy test starting with a an @key
> that
> runs a 500 count loop that runs a system command that just has
> system noredraw "echo you should not see this >/dev/null 2>&1"
> 
> then add progressively more to the system command to bring it closer to
> emulating the real command until it starts failing.
> 
> next I'd just add the counter variable
> system noredraw "echo you should not see this" < ct <" >/dev/null 2>&1"
> 
> then
> system "echo 'url & query string' >/dev/null 2>&1"
> 
> then a wget command but a simple one with a static url and no query string
> 
> then one that looks just like the real one, but fudge the cgi script name
> so
> it doesn't hit the real cgi, and use static dummy data in place of the
> variables
> 
> then use rand() in place of the variables so the data is no longer static
> without having to go through hoops to get real data from other records
> 
> if none of that fails, then you probably have something wrong with the
> data
> in the varibles being used in the real command, not with the command
> itself
> Or, if some version of the fake command fails then the problem depends on
> which version fails, and exactly how.
> 
> I'd also change those /dev/nulls to temp file names that are really unique
> and look at them
> maybe put a read command in the system command at the end to make it pause
> for a carriage return (specifically that way instead of "show @" to avoid
> the confision of fp even touching the screen at all during the loop) that
> way when it fails, you'll be able to see what temp files to look in for
> clues, or just see the clue on screen maybe.
> 
> Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR

     Thanks for all the great testing ideas.  If I can't find a quick fix,
I'm going to have to dig into this deeper.

     I can do a CLS("11","5) on a couple of the wget calls, but I have one
I'm working on now to pass some info from the customer master file, and I
need all the screen space, so I can't pre-position the cursor to a big blank
area.

     I had this problem with one wget call about a year or two ago, and I
took care of it with the CLS.  This wget call that suddenly started
malfunctioning was also written around the same time, but it hasn't acted up
until now.  The only thing I can see that has changed is that the Unix Box
is hit harder by more users than it was last year at this time.

Thanks again!

Mike