I've written a script and have been testing it from my shell account - this is just a little example to give you an idea...

print "Something\n";
sleep(2);
print "Something\n";

....now, as it is it will load for 2 seconds and then print:

Something
Something

....that sucks, so I'm flushing the buffer so it goes:

Something

Wait 2 seconds

Something

....this works as expected from my shell account but it won't work from my browser. I just works as if I hadn't flushed any buffers....how do I get it to work the same way as from my shell account?

That's a really good question...I would like to know this too...I know that sleep doesn't work. That's because the it just halts the system for 2 seconds and then outputs the response. On a webpage you can't emulate this web time unless you use some kind of real-time wating time. I know you can do this in Java applets but I don't know how to do it in Perl. All sleep(2) will do is take longer to relay the whole page back to the user, unless you can bypass this with an HTML page refresh, which is JavaScript I believe.

---

Crapshoot70 (this isn't my real name)
--
I don't like anyone...but everyone LOVES me
--
AKA...The Post Pirate

>>I know that sleep doesn't work. That's because the it just halts the system for 2 seconds and then outputs the response.<<

No sleep isn't what Im using to flush the buffer, that is $| = 1 ...sleep is just a little test which will let me know whether the buffer is flushing or not.

That made a cool 'woosh' sound as it traveled over my head at 50 kph

mabye i should read that Programming Perl book by O'reilly and Associates one more time...whadda ya think Paul?

---

Crapshoot70 (this isn't my real name)
--
I don't like anyone...but everyone LOVES me
--
AKA...The Post Pirate

Try the following two scripts and you should see what I mean....

so what is $|??? is that a special variable for buffering events? <<<Thats the PERL question.

But if you want to emulate wait times on a webpage you are going to have to set a timer to take care of this. Like, output the first line, then wait 2 seconds, then refresh the page with the second line on it. That is as far as it goes though I think. If you look at "real-time" chats you can kinda figure this out. It just refreshes the page every couple of seconds or...refreshes the page whenever any user in the chat room inputs some text.

---

Crapshoot70 (this isn't my real name)
--
I don't like anyone...but everyone LOVES me
--
AKA...The Post Pirate

$| causes perl to flush the buffers after every write/print

>>
But if you want to emulate wait times on a webpage you are going to have to set a timer to take care of this. Like, output the first line, then wait 2 seconds, then refresh the page with the second line on it.
<<

Im sure it can be done without a refresh...infact I've seen scripts that do traceroutes and it prints to your browser after each hop.

So we have come this far have we...Why was I not informed?

---

Crapshoot70 (this isn't my real name)
--
I don't like anyone...but everyone LOVES me
--
AKA...The Post Pirate

Do a search for "non-parsed headers" and read the FAQs related to that.

It your web server 'fault' - nothing to do with Perl.

- wil

Hehe I'm dense...totally forgot about that.

This will work with an nph- script.


Thanks for the reminder. It must be that picture of homer making me go stupid.

LOL. Don't worry. I got stuck on this one a while back.

The one thing I did discover, though, was that IE really sucks if you tweak too much with the headers yourself.

- wil

Hmm I spoke too soon....it didn't work...it just waited until the script was finished and showed all output at once.

I wonder if I need to make any changes to apache to get nph- scripts to work?

For mod_perl you need:

<Files */nph-*>
PerlSendHeader Off
</Files>

What did you name your script?

- wil

nph-test.cgi

What browser did you try it on? nph scripts work fine for me in Mozilla.

IE really sucks at handling nph script. In fact, I'm not sure if it even does.

- wil

The links 2 nph scripts work for me with IE so I must have screwed something up.

You lifted that example from here, right?

http://www.oreilly.com/...ook/cgi/ch03_08.html

I copied and pasted that and ran it under Mozilla 1 and everything works fine. I run it under IE and it just borkes out.

I remember reading somewhere that IE has little or no support at all for these nph scripts that continually push content.

- wil

Yep, I was right. Server-push is a Netscape technology and is available in Netscape and Mozilla browsers.

IE never caught on and supported it, even though it lies in it's user agent calling itself 'mozilla compatible {grin}.

You'll have to use client-pull, which really really sucks, if you want this to work in Microsoft browsers.

Try your example with Mozilla and it should work.

- wil

Yet another reason why IE sucks... {sigh}.

- wil

Yeah but it does work with IE...like I said, Links2 nph scripts work fine.

Aha. I take /nearly/ all my words back.

It's all to do with outputting headers, obviously. But it seems that IE is much more strict and Mozilla is much more forgiving.

So, I decided to use a module to clean it all up.

Go to CPAN and look for CGI::Push. Here's some example code that works for me:


Note that there is a much better example available in the POD on CPAN.

Hope this helps.

- wil

IE 5.1 still chokes on those headers... btw IE does work with progressive nph display (like the traceroute example) all the way back to IE4, just not the multi-part mime (think of it as screen refresh). When I was researching this a few weeks ago to do a "please wait" screen until the data was ready, I settled on using progressive nph with some JavaScript/layer tricks to hide and unhide elemetns as needed.

It does work with IE. Check out the following example:

http://www.wiley.com/...in/code/nph-push.cgi

And the source code:

http://www.wiley.com/...in/text/nph-push.txt

- wil

Wil, I'm not going to argue with you, but multipart MIME headers simply do not work with IE 5.1 (or earlier). We went through this before and I was thorough. Perhaps with 5.5 or later, and perhaps in 5.1 if I install the MS XML support update judging from the CPAN example which is using XML headers (but I didn't care to test the later, since 85% of my users use IE 5.0|1 out of the box anyways).

The output from your earlier example is quoted in my message above. The output of the Stein example is exactly what I expected... no mime support, just multiple iterations on one page with the mime headers printed out in plain text.