The impression I get from your description here is different from what I got out of our conversation on the ChatterBox. For one, you never said you had access to the source of the CGI script you want to change the output from. I assumed that that page came from the outside world. So it's an entirely different kettle of fish, now.

Anyway, I've given this some thought, and I must say that your solution seems a bit, er, user-unfriendly. I would think of a more sofisticated solution, completely automatic, and more deeply entwined with the original script. That might pose some problems on the collaboration level with your vendor, because the easy solution to do that, would be to modify the original script.

What I would attempt, is to let the running of the data fetching script be triggered by the loading of that page. In order for it to be efficient, you'll have to tweak the whole system a little. For example, you might not want this script to run more than once every five minutes or so, depending on how long a run takes, and how resource-hungry it is. So it would need to leave a timestamp mark of the "last run" somewhere, and your launcher script could check that before even firing it up. Another valid test could be to check first if any new data has come in. If not, you can skip the run entirely. This means the system has to be tweaked to set a flag (or a timestamp marker) everytime new data does come in. I think you get the picture by now...

How can you make this as unobstrusive as possible? If your script runs on the same machine as the original CGI script, just start up the external script with a system() call, or with one of the more elaborate (double) fork schemes, exec, etc. in the CGI script.

If it doesn't run on the same machine, make your launcher script a CGI script that outputs a 1-pixel transparent GIF (just copy the contents of such an image to STDOUT — with an appropriate content-type header, of course), and place that image in the HTML page. It's a trick web that stat counters often use.

--
bart