Doc #79905 [Opn]: Console-less environments do not prevent std streams to be opened
Edit report at https://bugs.php.net/bug.php?id=79905&edit=1
ID: 79905
Updated by: bukka@php.net
Reported by: chokolatrix at gmail dot com
Summary: Console-less environments do not prevent std streams
to be opened
Status: Open
Type: Documentation Problem
-Package: Filesystem function related
+Package: CGI/CLI related
Operating System: WINDOWS
PHP Version: 7.4.8
Block user comment: N
Private report: N
New Comment:
So this is specific to CGI SAPI and it might be also good to check if it can do the same thing on
Windows as FPM does on Linux - it means redirect those streams to be still usable.
Previous Comments:
------------------------------------------------------------------------
[2021-12-14 11:45:06] cmb@php.net
> The fact that PHP allows to open php://stderr is certainly a bug
> in this case.
While that is indeed not nice, and could be prevented, the more
serious issue is that php://stdin can be opened, but reading from
it would likely hang indefinitely under FCGI, since stdin is
actually FCGI_LISTENSOCK_FILENO (i.e. a pipe on Windows), and
detecting this is non-trivial, unless we would expose that info
from the SAPIs.
It's probably best to leave the implementation as is, and to
document the limitation instead.
------------------------------------------------------------------------
[2021-12-09 17:54:28] cmb@php.net
> The fact that opening the 'output', 'input', 'stdin',
> 'stderr' and
> 'fd' protocols completly ignores the given $mode[1], looks
> actually wrong to me.
On further consideration, I don't think that qualifies as a bug;
it is merely something to be documented, and that has been
done[1]. Emitting a notice if a mode is passed which does not
match, might be an improvement, but is not strictly necessary.
It is also not necessary to give an option to open php://stderr in
read-write mode; while POSIX mandates[2] that stderr is expected
to be open for reading and writing, this is not supported on
Windows, and likely there is no real need for that. Furthermore,
on CLI, STDERR could be used instead, what is supposed to follow
POSIX semantics on POSIX conforming platforms.
[1] <https://github.com/php/doc-en/commit/c5c3a4153df3b8c8007a33488f676e31b8e0f906>
[2] <https://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html>
------------------------------------------------------------------------
[2020-09-22 09:15:02] cmb@php.net
Related To: Bug #76086
------------------------------------------------------------------------
[2020-07-30 12:56:20] cmb@php.net
The fact that opening the 'output', 'input', 'stdin',
'stderr' and
'fd' protocols completly ignores the given $mode[1], looks
actually wrong to me.
However, on Windows with IIS *F*CGI there is usually no stderr
(nor stdout for that matter); all communication with the Webserver
is done through a pipe. The fact that PHP allows to open
php://stderr is certainly a bug in this case.
[1] <https://github.com/php/php-src/blob/php-7.4.8/ext/standard/php_fopen_wrapper.c#L215-L341>
------------------------------------------------------------------------
[2020-07-28 12:08:30] chokolatrix at gmail dot com
Related: https://bugs.php.net/bug.php?id=79166
------------------------------------------------------------------------
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=79905
--
Edit this bug report at https://bugs.php.net/bug.php?id=79905&edit=1
Thread (2 messages)