Mysterious Script Stops When Getting Files

[Eric Walker]

I am a php beginner, so apologize if this question is silly.

I am encountering apparently random script stops when I try to
get a remote HTML file with either file() or fopen(). A
typical code snippet:

echo 'here we go...';
$handle=fopen($url,'r');
echo 'and here we are';
if ($handle==FALSE)
{
do some stuff
}

I can try to use that to obtain several hundred similar files,
and have it go through a dozen or a hundred of them getting,
every time,

here we go...and here we are

and, more important, the file read just fine. But, sooner
or later in such a run, I will get the first echoed message but
not the second (that is, "here we go..." and nothing else) and
the script will have stopped dead. I have this in the script:

function bye()
{
echo 'SHUT DOWN!'.$p;
}
register_shutdown_function('bye');

I never see that message when it stops (though i do if the
script hits an exit statement). I also have this:

set_time_limit(0);

The php version is 4.2.2 on a server running BSD.

I encounter exactly the same behavior trying to fetch files
using

$remotefile=file($url);

On random occasions it just never comes out of the function.

This is driving me mad. Can anyone tell me what I am doing
wrong?
--
Cordially,
Eric Walker
Owlcroft House

[Eric Walker]

On 02 Sep 2003 10:27:37 GMT, Peter Jones wrote:

"Eric Walker" <ew*****@owlcroft.com> wrote in
news:rj********************************@news.indi vidual.net:

I am a php beginner, so apologize if this question is silly.

I am encountering apparently random script stops when I try
to get a remote HTML file with either file() or fopen(). A
typical code snippet:

echo 'here we go...';
$handle=fopen($url,'r');
echo 'and here we are';
if ($handle==FALSE)
{
do some stuff
}
else fclose($handle);

I would imagine you are hitting the system limit on
concurrently open files, if there isn't an fclose() somewhere
closing them again... Adding the above line ought to fix
that.

Sorry, no, it isn't that. For simplicity's sake, I just showed
the immediately relevant lines in the snippet; there is indeed
a line--

if ($handle!==FALSE) fclose $handle;

farther on.

PS: Is that logic correct? 'do some stuff' if file did NOT
open?

Some error-recording stuff, yes, and re-try logic; there is
also continuing script that proceeds if the handle is valid
(and which eventually gets to that file-close). But the script
never gets to use anything in that block because it never
emerges from the file-open (or, with file(), file-get) function
call.

What especially puzzles me is that the script apparently
doesn't even activate the registered shutdown function when it
quits: it just . . . stops.
--
Cordially,
Eric Walker
My opinions on English are available at
http://owlcroft.com/english/

[Krisztian VASAS]

Eric Walker wrote:

On 02 Sep 2003 10:27:37 GMT, Peter Jones wrote:

"Eric Walker" <ew*****@owlcroft.com> wrote in
news:rj********************************@news.ind ividual.net:

I am a php beginner, so apologize if this question is silly.

I am encountering apparently random script stops when I try
to get a remote HTML file with either file() or fopen(). A
typical code snippet:

echo 'here we go...';
$handle=fopen($url,'r');
echo 'and here we are';
if ($handle==FALSE)
{
do some stuff
}
else fclose($handle);

I would imagine you are hitting the system limit on
concurrently open files, if there isn't an fclose() somewhere
closing them again... Adding the above line ought to fix
that.

Sorry, no, it isn't that. For simplicity's sake, I just showed
the immediately relevant lines in the snippet; there is indeed
a line--

if ($handle!==FALSE) fclose $handle;

farther on.

Dummy question: see the allow_url_fopen in php.ini whether it is
enabled. If not, then enable it...

PS: Is that logic correct? 'do some stuff' if file did NOT
open?

Some error-recording stuff, yes, and re-try logic; there is
also continuing script that proceeds if the handle is valid
(and which eventually gets to that file-close). But the script
never gets to use anything in that block because it never
emerges from the file-open (or, with file(), file-get) function
call.

What especially puzzles me is that the script apparently
doesn't even activate the registered shutdown function when it
quits: it just . . . stops.

if ($handle!==FALSE) fclose $handle;

or:

if ($handle!=FALSE) fclose $handle;
IroNiQ
--
Web: http://ironiq.hu/
Email: ir**@ironiq.hu

[Mark Hewitt]

"Peter Jones" <jo*****@optushome.com.au> wrote in message
news:Xn*****************************@210.49.20.254 ...

"Eric Walker" <ew*****@owlcroft.com> wrote in
news:rj********************************@news.indiv idual.net:

On 02 Sep 2003 10:27:37 GMT, Peter Jones wrote:
[snip]
Sorry, no, it isn't that. For simplicity's sake, I just showed
the immediately relevant lines in the snippet; there is indeed
a line--

if ($handle!==FALSE) fclose $handle;

farther on.

[snip]
(Also, as Krisztian pointed out, it should probably be "!=" rather than
"!==", although simple testing on my part seems to suggest "!==" is
working the same way as "!=". According to the precedence rules it should
be parsing as "((!)==)" -- but actual usage of such a construct may well
be undefined and therefore not do what you think it will...)

No, !== is quite different to !=, as is === to ==
Look at Comparison operators in PHP manual

$x = 0;
$y = false;

if ( $x === false ) { // this is not true, x is not FALSE, its 0 }
if ( $y === false ) { // this is true }
if ( !$x ) { // this is true, 0 is classed as a logical false, but it does
not have the _type_ false, it is type integer }

Similary for !== ....
if ( $x !== false ) { // true, it is type interger, no false, despite the
fact that.... if ( !$x ) would be true
if ( $y !== false ) { // false, y does have type false ... }
I mut say here I do tend to test for :

if ( $handle ) { fclose($handle); }

myself, it reads easier, but i guess...

if ( $handle !== false ) { ... }

is more strictly correct, becuase fopen returns false on failure, so
if ( $handle === false ) { it failed... }
conversly
if ( $handle !== false ) { it worked }

This means should file handles suddenly start allowing 0 as a file handle it
would still work.

Thanks
Mark
---------------------------------------------------------------------------
Windows, Linux and Internet Development Consultant
Email: co*******@scriptsmiths.com
Web: http://www.scriptsmiths.com
---------------------------------------------------------------------------
[snip]


HTH,
Pete.

[Eric Walker]

On 03 Sep 2003 13:27:06 GMT, Peter Jones wrote:

"Eric Walker" <ew*****@owlcroft.com> wrote in
news:rj********************************@news.indi vidual.net:

On 02 Sep 2003 10:27:37 GMT, Peter Jones wrote:

I would imagine you are hitting the system limit on
concurrently open files, if there isn't an fclose()
somewhere closing them again...

Sorry, no, it isn't that. For simplicity's sake, I just
showed the immediately relevant lines in the snippet; there
is indeed a line--

if ($handle!==FALSE) fclose $handle;

farther on.

Are you sure that the script is actually reaching (and
correctly processing) the fclose()? Also, are you sure you
are not reassigning the value of $handle somewhere before you
do the fclose($handle) -- something I've been caught by a time
or two in the past...

I am sure. Moreover, the problem originally arose using
file(), which does not involve an explicit open/close process
using a handle; I only went back to fopen/fclose to see if that
would work any better (it didn't).

[...]

What especially puzzles me is that the script apparently
doesn't even activate the registered shutdown function when
it quits: it just . . . stops.

The only other thing I can think to suggest is to specifically
check which file it is stopping on. Is it the same file each
time? If so, is there something else accessing that file at
the same time?

No, not the same file each time: the "problem" file will be one
that, on the next run, will be picked up just fine (and
probably was on an earlier run)--it doesn't seem to be
associated with the file being sought (though it may reflect
something dicey in the server's behavior or returned headers--I
haven't tried to look at those). Incidentally, the problem
arise both with files off remote servers (such as Amazon and
ESPN) and with php scripts of mine on my ISP's own server.

Maddening!
--
Cordially,
Eric Walker
My opinions on English are available at
http://owlcroft.com/english/

[Peter Jones]

"Mark Hewitt" <co*******@scriptsmiths.com> wrote in
news:3f**************@hades.is.co.za:

No, !== is quite different to !=, as is === to ==
Look at Comparison operators in PHP manual

Thanks, Mark, for elaborating on that. I did actually look in my near-to-
hand reference for "!==" before I allowed myself to post under the premise
that it was invalid. My reference ('PHP and MySQL Web Development') mentions
"===" but not "!==". I guess I've learned two things -- one being that I
can't necessarily totally trust this book now... :-)

I guess "!==" is to "===" as "!=" is to "=="?!

Apologies all round for taking the discussion down a false trail.

Pete.

[CC Zona]

In article <Xn*****************************@210.49.20.254>,
Peter Jones <jo*****@optushome.com.au> wrote:

I guess "!==" is to "===" as "!=" is to "=="?!

Correct. The former set evaluates value and type, while the latter set
evaluates only value. So, for instance:

1==TRUE //because their values evaluate as equivalent

-but-

1!==TRUE //because a boolean is not an integer

--
CC