in proc_open:

 if (strncmp(Z_STRVAL_PP(zmode), "w", 1) != 0) {
                    descriptors[ndesc].parentend = newpipe[1];
                    descriptors[ndesc].childend = newpipe[0];
                    descriptors[ndesc].mode |= DESC_PARENT_MODE_WRITE;
                } else {
                    descriptors[ndesc].parentend = newpipe[0];
                    descriptors[ndesc].childend = newpipe[1];
                }


so, it's very clear why no notice was raised(assume "r" by default). considering bc issue, and not very helpful notices....

maybe change to a doc issue is better.

I found the issue in my code because I was passing in "a" as recommended in http://php.net/proc_open#97012 and I wasn't getting any output.

I'm pretty confident it used to work, so to me it seems BC has already been broken, as it's changed from working to failing silently - I'd rather it changed from working to giving an error (/warning/notice).

This code has not been changed since 2003[1], so it's somewhat
unlikely that a BC break has been introduced in PHP 5.x.y. If you
can reproduce a behavioral change, please let us know (and change
the bug status back to "Open").

[1] <https://github.com/php/php-src/commit/1a314027d3c388a19a06ac370fa08a46d474e1bd#diff-19f692ed5f75687fc7bc1929910e540fR337>

I've tested the script below with these results (sorry, I can't run these on the same OS):

PHP:    5.3.5
OS:     Win XP
Mode:   w
Result: Script hangs

PHP:    5.3.5
OS:     Win XP
Mode:   a
Result: Empty string

PHP:    5.5.13
OS:     Win 7
Mode:   w
Result: string 'x.......'

PHP:    5.5.13
OS:     Win 7
Mode:   a
Result: Empty string

So the behavior has changed somewhat between 5.3 and 5.5, but not in the way I thought...
It looks like the "a" mode never actually worked (as the output was empty), but just tricked PHP/Windows into not hanging.
I still think failing silently is a really bad thing though.



<?php

$descriptors = array(
	array('pipe', 'r'),
	array('pipe', 'w'),
	array('pipe', 'w'), // This one changes between 'a' and 'w'
);
		
$process = proc_open('c:\php\php.exe -r "$f = fopen(\'php://stderr\', \'w+\');fwrite($f, str_repeat(\'x\' . chr(10), 2048));', $descriptors, $pipes);
var_dump(stream_get_contents($pipes[1]));
var_dump(stream_get_contents($pipes[2]));
proc_close($process);

Status

@roborg thanks for the report.

With the script hanging, I guess you're hitting the bug #51800 in 5.3 which was fixed in 5.5+ around last autumn. Pipe buffer on windows is way too small and can cause race conditions. Please check, if it's so - we can close this.

Besides that, something standing in the comments is not the documentation, so it makes absolutely no sense to claim it a bug if it doesn't work.

Thanks.

Hi

This isn't really related to #51800 - that's just how I found out that my script wasn't working.

I understand BC is a concern, but the only scripts affected by this are ones that aren't working anyway - they're just failing silently, which in my opinion is much worse than generating an error of some level (even just a notice).

If you pass in an invalid value for the first parameter e.g. change 'pipe' to 'foo' then you get an error - I can't see a reason that the mode parameter shouldn't be checked as well.

I guess if silently failing is what was intended then this is more of a feature request than a bug report so I'll update the type.

> I understand BC is a concern, but the only scripts affected by
> this are ones that aren't working anyway - they're just failing
> silently, which in my opinion is much worse than generating an
> error of some level (even just a notice).

Not quite.  Anthing else than 'w' is treated like 'r', like
@laruence already stated above.

Anyhow, no progress after more than six years makes me think it's
better to document the behavior than to wait for someone to
implement this feature request.