Scott, you worked on the re2c switch, any chance you can clarrify this one?

The sapi/cli/php_cli.c code will read forward when it see's a shebang  to the next line. The file is already seeked by the time the scanner gets a change to look at it.

The zend_get_scanned_file_offset() doesn't know about this because by the time the scanner is started the bytes are already long gone.

Short of a global variable I'm not seeing a clean way to fix this.

Understandably this might be a bit hackish to have use a global variable 
here, but perhaps thats preferable to what i'd consider a major 
regression?

I attempted to patch this so I could just submit a patch here, but 
unfortunately my c-fu and my understanding of PHP internals is lacking.

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Since the shebang check was removed from scanner, isn't this issue 
solved then? (please try :)

Nevermind, of course it's still borked since the check is NOT done in 
scanner. :)

We also hit this bug, because we have a custom php-based installer that uses __halt_compiler() and __COMPILER_HALT_OFFSET__ to extract a tar.gz portion of the installer.
Since PHP 5.3 our installers do not work anymore! :-(
Is a fix not even planned at this stage??

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Hi felipe,
Thanks for taking a look at this bug, its languished for (what i'd consider) far 
too long.
Unfortunately it doesn't seem to fix the issue:

-=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:14:16]=-
[adam@nighe]$ ./sapi/cli/php -v
PHP 5.3.3RC2-dev (cli) (built: Jun 27 2010 17:54:04) 
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
-=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:11]=-
[adam@nighe]$ php -v
PHP 5.3.1 (cli) (built: Dec 26 2009 19:21:45) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
-=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:15]=-
[adam@nighe]$ ./sapi/cli/php test-without-shebang.php 
string(19) "
this is test data
"
-=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:30]=-
[adam@nighe]$ ./sapi/cli/php test-with-shebang.php 
string(40) ");
__halt_compiler();
this is test data
"
-=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:34]=-
[adam@nighe]$ php test-with-shebang.php 
string(40) ");
__halt_compiler();
this is test data
"
-=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:38]=-
[adam@nighe]$ php test-without-shebang.php 
string(19) "
this is test data
"
-=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:44]=-
[adam@nighe]$ cat test-without-shebang.php 
<?php
$fh=fopen(__FILE__,"r");
fseek($fh,__COMPILER_HALT_OFFSET__);
var_dump(fread($fh,1024));
fclose($fh);
__halt_compiler();
this is test data
-=[~/Scripts/compile/php5.3-201006272030]=- -=[Sun Jun 27]=- -=[18:15:54]=-
[adam@nighe]$ cat test-with-shebang.php 
#!/usr/local/bin/php
<?php
$fh=fopen(__FILE__,"r");
fseek($fh,__COMPILER_HALT_OFFSET__);
var_dump(fread($fh,1024));
fclose($fh);
__halt_compiler();
this is test data

I lied, It just hasn't hit the snapshots yet, works from SVN sources!

-=[~/Scripts/compile/php-src-5.3]=- -=[Sun Jun 27]=- -=[18:40:12]=-
[adam@nighe]$ ./sapi/cli/php test-with-shebang.php 
string(19) "
this is test data
"
-=[~/Scripts/compile/php-src-5.3]=- -=[Sun Jun 27]=- -=[18:40:17]=-
[adam@nighe]$ ./sapi/cli/php test-without-shebang.php 
string(19) "
this is test data
"


Thanks very much felipe!

The fix has been reverted for 5.3 branch because it breaks binary compatibility.

Thats awesome....

Can you fix the status of this bug then, its not closed nor is it resolved.

It is fixed in trunk, so technically it has been fixed.  It may be a "Can't Fix" 
for 5.3 if Felipe can't find a way to fix it without breaking binary compatibility 
in a minor release version.

I've committed a new fix for this bug, in 5.3 and trunk.