Just to follow up ...

I get the hash-bang line output even when running the script from the shell (i.e. not from cron).

Help!

You must be running them through stdin ex "php < file".
If so, this is not a bug

If you are using shebang, you should just execute the script ./script. If you have to run php manualy then you will need to pass files in as args, not as stdin 

ex. php file1.php

I'm not running them through STDIN.
I'm running them right from the command line:

     ./script.phx

...or from cron:

     15 1,13 * * *    /path/to/my/script.phx

Or am I misunderstanding you?

(the script files start with "#!/path/to/php -q")

- Colin

The way you are using this should not have any problems.
I have not been able to reproduce this. What is your compile string?

Also, can you try running the standalone as follows? :
/path/to/php /path/to/test-file.php

By the way, a temporary work around for your cron job, until we solve your problem would be

grep -v '#!' /path/to/my/script.phx | /path/to/php

My configure line is:

./configure --with-mysql=/usr/local/mysql \
--with-apxs=/usr/local/apache/bin/apxs
--enable-track-vars
--disable-debug
--disable-magic-quotes
--enable-ftp
--with-gettext
--with-xml
--with-dom
--enable-wddx
--with-curl
--with-pgsql
--with-zlib
--enable-versioning
--with-openssl
--with-snmp
--with-sablot
--with-mcrypt

Running the standalone as:
    /path/to/php /path/to/test-file.php
also outputs the hash-bang line (but that's expected, since it's outside of <? ?> tags and would get treated as HTML).

Your grep suggestion works ... kludgy, but it works.  I just think there must be something wrong in PHP since I used to run scripts through cron like this all the time without incident.

- Colin

Is the configure script you used to produce the standalone the same?

"--with-apxs=/usr/local/apache/bin/apxs"
caught my attention.

Did you compile the standalone with symbols?
If you did and feel like running it through a debugger

gdb /path/to/php
break 699
run /path/to/script/file.php

see if that if statement evaluates as true... it is supposed to(But by your description it sounds like it isnt). You will notice the comment pruneing code lies in a true result of that condition.

If you get stuck why dont you email me a copy of your php binary.
About the kludgy solution, I know it was painful to put that in. Don't worry though it will be gone soon : )

-Jason

colin>/path/to/php /path/to/test-file.php
colin>also outputs the hash-bang line (but that's expected, colin>since it's outside of <? ?>
colin>tags and would get treated as HTML).

Actually the way Unix treats shebangs is to tracnslate
#!/bin/program
to
/bin/program script

So php has code to prune '#'s' out of the statements.
But the code just double checks its not stdin thats being parsed.


Is the configure script you used to produce the standalone the same?

"--with-apxs=/usr/local/apache/bin/apxs"
caught my attention.

Did you compile the standalone with symbols?
If you did and feel like running it through a debugger

gdb /path/to/php
break 699
run /path/to/script/file.php

see if that if statement evaluates as true... it is supposed to(But by your description it sounds like it isnt). You will notice the comment pruneing code lies in a true result of that condition.

If you get stuck why dont you email me a copy of your php binary.
About the kludgy solution, I know it was painful to put that in. Don't worry though it will be gone soon : )

-Jason

#! works for me in latest CVS... 

Oopos, I posted the configure line for the apache version running on the same box.  The standalone's config line is the same without the apxs:

./configure --with-mysql=/usr/local/mysql \
--enable-track-vars \
--disable-debug \
--disable-magic-quotes \
--enable-ftp \
--with-gettext \
--with-xml \
--with-dom \
--enable-wddx \
--with-curl \
--with-pgsql \
--with-zlib \
--enable-versioning \
--with-openssl \
--with-snmp \
--with-sablot \
--with-mcrypt


As for the gdb suggestion:

[cmv@vincent cmv]$ gdb /usr/local/bin/php
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) break 699
Breakpoint 1 at 0x80619c4: file cgi_main.c, line 699.
(gdb) run /usr/local/bin/test.phx
Starting program: /usr/local/bin/php /usr/local/bin/test.phx

Breakpoint 1, main (argc=2, argv=0xbffffac4) at cgi_main.c:699
699             } else if (file_handle.handle.fp && file_handle.handle.fp!=stdin) {
(gdb) bt
#0  main (argc=2, argv=0xbffffac4) at cgi_main.c:699


I'm no gdb expert, so if I'm doing this wrong, let me know.

Jason, if you want me to email you my php binary, let me know (send me a direct email to the address above).

I see that stas has no probs with the latest CVS, so I may just grab that.  Would be nice to know why this broke with 4.0.3pl1 though ....

- Colin

I think it would be good for you to try CVS, but you might not see a difference. I have been having problems reproducing this bug, it seems to work fine for me on 4.0.3pl1 as well as CVS.  


Here is better gdb instructions:

break 699
run /usr/local/bin/test.phx
next
next
next

send the output ... I just want to see what line number it jumps to next...it is supposed to proceed to line 701 where 
it will prune commented code.

No response from user, could not be reproduced.

Oops ... my responses were "off-list".

This seems to be fixed in the 4.0.4 and 4.0.5 CVS.