proc_open is using a wrong initial working dir

Bug #50524

Submitted:

2009-12-18 19:33 UTC

Modified:

2013-02-18 00:34 UTC

Votes:	4
Avg. Score:	3.5 ± 0.9
Reproduced:	2 of 2 (100.0%)
Same Version:	0 (0.0%)
Same OS:	0 (0.0%)

From:

carsten_sttgt at gmx dot de

Assigned:

pajoye (profile)

Status:

No Feedback

Package:

Program Execution

PHP Version:

5.3.1

OS:

win32 only

Private report:

CVE-ID:

None

[2009-12-18 19:33 UTC] carsten_sttgt at gmx dot de

Description:
------------
Hello,

each program execution function:
- exec()
- passthru()
- shell_exec()
- system()
- backtick operator
or popen() is using the current script (working) directory as working directory for the command which is executed.

Only proc_open() is using a different directory:
- for apache2handler it the Apache ServerRoot
- for CGI it's the php-cgi.exe directory
- for FastCGI (mod_fgcid) it's also the php-cgi.exe directory

On *nix (mod_fcgid) the proc_open() working directory is as expected also the script (working) directory.

Regards,
Carsten


Reproduce code:
---------------
<?php
header('Content-Type: text/plain');
echo "------getcwd()---------\n";
echo getcwd()."\n\n";


echo "\n\n-------popen()---------\n";
if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') {
    $cmd = 'dir';
} else {
    $cmd = 'ls';
}
$process = popen($cmd, 'r');
while (!feof($process)) {
    echo fread($process, 80);
}
pclose($process);


echo "\n\n-------passthru()------\n";
passthru($cmd);


echo "\n\n------proc_open()------\n";
$descriptorspec = array(
   0 => array('pipe', 'r'),
   1 => array('pipe', 'w'),
   2 => array('pipe', 'w')
);
$process = proc_open($cmd, $descriptorspec, $pipes);
while (!feof($pipes[1])) {
   echo fread($pipes[1], 80);
}
fclose($pipes[0]);
fclose($pipes[1]);
fclose($pipes[2]);
proc_close($process);
?>


Expected result:
----------------
getcwd:
C:\Apache2.2\htdocs

3 times a directory listing of:
C:\Apache2.2\htdocs

Actual result:
--------------
getcwd:
C:\Apache2.2\htdocs

2 times (popen, passthru) a directory listing of:
C:\Apache2.2\htdocs

1 time (proc_open) a directory listing of:
apache2handler: C:\Apache2.2
or CGI/FastCGI: C:\PHP

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2009-12-23 13:56 UTC] kalle@php.net

This is expected, as also noted in the manual on the proc_open() page for the $cwd parameter. If NULL is supplied to $cwd, then on Windows atleast the directory where the PHP script interpreter is located is the cwd.

[2009-12-23 14:22 UTC] carsten_sttgt at gmx dot de

> This is expected,

No, a different behavior on Linux/BSD/OS X and Windows is not expected.

(and also between proc_open and the other program execution functions)


> as also noted in the manual on the proc_open() page for the $cwd parameter.

Well,
> or NULL  if you want to use the default value
> (the working dir of the current PHP process)

If you really test the script yourself, you can see that getcwd() is returning the correct working dir of the current PHP process, but proc_open is using something else.


> then on Windows atleast

This have nothing to do with Windows. Only a wrong usage of CreateProcess from the PHP developers in this case (lpCurrentDirectory is not set to the value of getcwd).

[2009-12-23 15:16 UTC] pajoye@php.net

Agreed, it should behave the same.

[2010-09-08 10:35 UTC] pajoye@php.net

-Status: Assigned +Status: Closed

[2010-09-08 10:35 UTC] pajoye@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

[2012-03-29 10:02 UTC] axel at zehden dot net

I have exactly this buggy behavior in my actual PHP 5.3.10 on Ubuntu.

With cwd parameter NULL, I get a wrong working dir.
This did not happen in the PHP 5.2, I used before.

[2013-01-07 12:13 UTC] pajoye@php.net

-Status: Closed +Status: Feedback

[2013-02-18 00:34 UTC] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.