php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #65557 Constants from Core are not defined with inline scripts
Submitted: 2013-08-26 08:49 UTC Modified: 2013-08-26 10:20 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: Laurent dot Lyaudet at gmail dot com Assigned:
Status: Verified Package: CGI/CLI related
PHP Version: 5.4 and later OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: Laurent dot Lyaudet at gmail dot com
New email:
PHP Version: OS:

 

 [2013-08-26 08:49 UTC] Laurent dot Lyaudet at gmail dot com 
Description:
------------
Hi,

I found a bug affecting PHP 5.3.3-7+squeeze15 and PHP 5.4.4-14+deb7u3 (cli) (latest debian package for current stable).
The constant STDERR is not defined for inline scripts. 
I mean it isn't defined when you type #php and then you type <?php myscriptcontent ?>, Ctrl+D.
But it works if you use php -r 'myscriptcontent'.
I join test script below.

I didn't tested it but I assume it is not specifically STDERR which is impacted.
It is probably the same for all Core constants.

Best regards,
   Laurent Lyaudet

Test script:
---------------
php -r 'fwrite(STDERR, "stderr\n");'

works but

root@wheezyDEVLaurent:~# php
<?php
fwrite(STDERR, "stderr\n");
?>

doesn't.

Expected result:
----------------
stderr

Actual result:
--------------
PHP Notice:  Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
PHP Stack trace:
PHP   1. {main}() -:0

Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3

Call Stack:
   10.9477     215280   1. {main}() -:0

PHP Warning:  fwrite() expects parameter 1 to be resource, string given in - on line 3
PHP Stack trace:
PHP   1. {main}() -:0
PHP   2. fwrite() -:3

Warning: fwrite() expects parameter 1 to be resource, string given in - on line 3

Call Stack:
   10.9477     215280   1. {main}() -:0
   10.9479     216048   2. fwrite() -:3

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-08-26 09:06 UTC] Laurent dot Lyaudet at gmail dot com 
Additionally I noted that 
#echo '<?php fwrite(STDERR, "stderr\n"); ?>' > test
#php test
works.

Is is somehow surprising since I would have thought that the only difference between "php test" and "php <?php fwrite(STDERR, "stderr\n"); ?>" was the input stream for php code.
 [2013-08-26 09:09 UTC] yohgaki@php.net
-Status: Open +Status: Verified -Operating System: Debian Linux +Operating System: Linux -PHP Version: 5.4.19 +PHP Version: 5.4 and later
 [2013-08-26 09:09 UTC] yohgaki@php.net 
[yohgaki@dev PHP-5.5]$ echo '<?php fwrite(STDERR, "stderr\n"); ' | ./sapi/cli/php

Warning: fwrite() expects parameter 1 to be resource, string given in - on line 1
 [2013-08-26 10:20 UTC] johannes@php.net 
This is done by purpose: We can't easily provide STDIN as that's bound to the script input and we either provide all three (STDIN, STDOUT, STERR) or none. 

Maybe this can be improved to rebind STDIN (and then providing all three) after the full script has been passed.

Maybe this trinity can be relaxed.

This requires some more analysis of the consequences.
 [2013-08-27 18:20 UTC] Laurent dot Lyaudet at gmail dot com 
Hi,

I thought that maybe we can alter the comportment of #php
You first type your script in the shell
<?php
...
?>
Ctrl+D -> you're still running php; STDIN, STDERR, etc. are initialized for the script
additional input provided to the script
Ctrl+D -> end of input to the script
I don't know if the shell enables this.
Moreover, it would require two Ctrl+D for users with no intent to give additional input.
Let me know what you think about it.

Best regards,
   Laurent
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 12:01:29 2024 UTC