Bug #74339 [Com]: BOGUS: Fatal error: strict_types declaration must be the very first statement

Edit report at https://bugs.php.net/bug.php?id=74339&edit=1 ID: 74339 Comment by: kevin at kevinlocke dot name Reported by: spam2 at rhsoft dot net Summary: BOGUS: Fatal error: strict_types declaration must be the very first statement Status: Not a bug Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 7.1.3 Block user comment: N Private report: N New Comment: This issue also occurs when CLI scripts are read from stdin by php (e.g. for linting). For example, if mycli.php has the following content: #!/usr/bin/php <?php declare(strict_types=1); echo "Hello World\n"; Running php -l mycli.php prints "No syntax errors detected in mycli.php". Running php -l < mycli.php (as some lint tools like ALE do) prints "PHP Fatal error: strict_types declaration must be the very first statement in the script in Standard input code on line 3". Previous Comments: ------------------------------------------------------------------------ [2019-01-19 17:50:54] spam2 at rhsoft dot net all the workarounds are fine but the first php staement is after <?php no matter how many shebangs and BOM are before and when i read something like "You shouldn't have CLI scripts within your webroot in the first place" i just get upset since the whole purpose of if(PHP_SAPI === 'cli') is to write proper software which bheaves corretly in CLI as well as in web-mode (require a web-login versus just do the job as example) ------------------------------------------------------------------------ [2019-01-18 16:36:17] stefansobick at gmx dot de Convert the file to utf without BOM, than it should work fine, when you have done it like this: <?php declare(strict_types=1); ?> <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Page title</title> </head> <body> ... ------------------------------------------------------------------------ [2017-04-07 13:14:12] spam2 at rhsoft dot net > You shouldn't have CLI scripts within your webroot in the first place ... really? #!/usr/bin/php <?php declare(strict_types=1); switch(PHP_SAPI} { case 'cli': break; default: break; } ...shared..code.... ?> i have ton of examples where this works pretty fine by intention while in cron mode the only output are errors and when runnigng in the browser authenticated against the CMS you get runtime informations maybe i am the only guy on this planet which is using PHP and cli heavily for a decade and write any code so that it is 100% cli capable including the whole CMS bootstrap but that don't change the fact that "You shouldn't have CLI scripts within your webroot" is nonsense and frankly on shared hosting you have usually no way to run CLI or palce something outside the webroot at all and so you need to make sure that these tasks can be called via web and be it that your conjob running somewhere else running curl('https://url/cron.php?username=bla&pwd=bla'); and you break that all for no reason with claim "declare(strict_types=1)" is not the first line while IT IS and even bobody would care about "#!/usr/bin/php" in the output when called via websevrer #!/usr/bin/php <?php declare(strict_types=1); ------------------------------------------------------------------------ [2017-04-07 12:18:49] narf at devilix dot net You shouldn't have CLI scripts within your webroot in the first place ... ------------------------------------------------------------------------ [2017-04-02 11:15:16] spam2 at rhsoft dot net than at least ignore shebangs also with mod_php #!/usr/bin/php <?php declare(strict_types=1); if(PHP_SAPI != 'cli') { exit('CLI ONLY'); } ?> is also broken when called via browser which leads to fatal erros and so flood logs which is bad in case of emial reporting every 30 minutes when any of some hundret vhsost triggers any php-warning/error ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74339 -- Edit this bug report at https://bugs.php.net/bug.php?id=74339&edit=1