Bug #77561 [Opn]: PHAR bootstrap script with shebang and strict types does not work
| From: | cmb@php.net | Date: | Mon, 04 Feb 2019 00:02:42 +0000 |
| Subject: | Bug #77561 [Opn]: PHAR bootstrap script with shebang and strict types does not work | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-219351@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=77561&edit=1
ID: 77561
Updated by: cmb@php.net
Reported by: sebastian@php.net
Summary: PHAR bootstrap script with shebang and strict types
does not work
Status: Open
Type: Bug
Package: PHAR related
Operating System: Irrelevant
PHP Version: 7.3.1
Block user comment: N
Private report: N
New Comment:
> the topic is about <?php declare(strict_types=1); and you come up with a simple missing the
> point?
My point is that PHP sees the whole file as a single script, and that everything outside of <?php
?> is simply ârewrittenâ to be echoed. E.g.
#!/usr/bin/env php
<?php declare(strict_types=1);
is compiled the same as
<?php
echo "#!/usr/bin/env php\n";
declare(strict_types=1);
So, declare is *not* the âvery first statement in the scriptâ.
Previous Comments:
------------------------------------------------------------------------
[2019-02-03 19:24:04] phpbugs at olemartin dot org
I agree with @cmb that the example with arbitrary content before the start tag should produce the
error. However, it's quite a gotcha that a shebang is stripped in some cases (when executed by
the cli) but not others (when included). Same should go with a BOM (and other magic numbers?).
Since there are partial support for shebangs, that support should be made consistent.
------------------------------------------------------------------------
[2019-02-03 18:34:55] spam2 at rhsoft dot net
@cmb seriously?
the topic is about <?php declare(strict_types=1); and you come up with a simple missing the
point?
[harry@srv-rhsoft:/downloads]$ cat test.php
foo
<?php declare(strict_types=1);
echo 'bar';
[harry@srv-rhsoft:/downloads]$ php test.php
Fatal error: strict_types declaration must be the very first statement in the script in
/mnt/data/downloads/test.php on line 2
[harry@srv-rhsoft:/downloads]$
------------------------------------------------------------------------
[2019-02-03 18:30:09] cmb@php.net
> the first php statement is after <?php
See <https://3v4l.org/m0YBG/vld#output>.
------------------------------------------------------------------------
[2019-02-03 17:50:19] spam2 at rhsoft dot net
nobody cares, i worte a bugreport long ago that it don't matter if it's an include or a
script called by mod_php or a BOM - the first php statement is after <?php and the special
handling for pure shell scripts with shebang is crap
"very first statement in the script"
not BOM nor shebang are script statements
------------------------------------------------------------------------
[2019-02-03 17:46:54] sebastian@php.net
Description:
------------
It seems that there is a bug in PHP that when a PHAR is include()d or require()d and the PHAR's
bootstrap script has a shebang such as "#!/usr/bin/env php" on its first line followed by
"<?php declare(strict_types=1);" on its second line then PHP wrongly triggers a
"strict_types declaration must be the very first statement in the script" compiler error.
See https://github.com/sebastianbergmann/phpunit/issues/3509
for an issue that showcases this problem in the context of PHPUnit's phpunit.phar.
I discussed this with Nikita who said "The strict_types error is correct, because the shebang
line is interpreted as literal output (and will be printed to stdout unless you intercept that
somehow). Shebangs are only stripped from the primary script if run via CLI. It would probably make
sense to always strip them instead. This can probably only be fixed in 7.4 at the earliest, as
it's a BC breaking change. Unless there is some phar-specific interaction here where it already
strips the shebang but not for the purpose of strict_types handling)."
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=77561&edit=1