|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2002-01-17 05:56 UTC] davidfelton at codemasters dot com
[2002-01-17 19:40 UTC] louis at steelbytes dot com
[2002-01-21 06:32 UTC] davidfelton at codemasters dot com
[2002-01-21 07:16 UTC] louis at steelbytes dot com
[2002-10-31 14:51 UTC] iliaa@php.net
[2002-11-16 01:00 UTC] php-bugs at lists dot php dot net
[2004-07-30 08:01 UTC] kaushy1 at yahoo dot com
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Oct 26 16:00:01 2025 UTC |
in 4.0.6, popen() would just call CreateProcess() with the specified command. this was ok. in 4.1.0 popen() now prepends "cmd.exe /c " (or "command.com /c " on win9x). the problem with this, is that many web admins will disable access for the web apps to access cmd.exe (eg, MS's IISLockDown does this), and hence even though the web app may have access to c:\utils\myapp.exe, a command like exec("c:\utils\myapp.exe") now fails on 4.1.0 but works on on 4.0.6. also, the hardcoding of cmd.exe should not be done. it should get it from the enviroment. summary: have commands that prepend the result of an enviroment lookup on "%comspec% /c " to the front of a command AND have commands that dont, so that I can call exec("c:\utils\myapp.exe"); without having to enable access to cmd.exe OR any interpretation of these issues, that allow for a sensible amount of flexibilty. Louis Solomon www.SteelBytes.com