php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #45913 include() environment during eval()
Submitted: 2008-08-25 19:02 UTC Modified: 2017-09-20 13:56 UTC
From: ganswijk at xs4all dot nl Assigned:
Status: Suspended Package: *General Issues
PHP Version: 5.3CVS-2008-08-25 (CVS) OS: irrelevant
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: ganswijk at xs4all dot nl
New email:
PHP Version: OS:

 

 [2008-08-25 19:02 UTC] ganswijk at xs4all dot nl
Description:
------------
I noticed that during the execution of an eval() the environment for an include() is kept the same as that of the original script executing the eval() but this probably often isn't the case, for example in the case of user contributed code to 'eval()'.

To overcome this problem I currently use:

$cwd=getcwd();
chdir(code-environment-of-code-to-eval);
eval(code-to-eval);
chdir($cwd);

But perhaps this could be solved in a better way?
Because in this I am assuming that the data
environment is the same as the code environment
for the code to eval().

BTW. I notice that PHP often makes no distinction
between the current working directory for code and
for data. I think that all the PHP definitions should
be rewritten to make this distinction in all relevant
cases.

BTW2. Perhaps there should even be different
workspaces for input and output data files...



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-09-20 13:56 UTC] cmb@php.net
-Status: Open +Status: Suspended -Package: Feature/Change Request +Package: *General Issues
 [2017-09-20 13:56 UTC] cmb@php.net
Thank you for your interest in PHP and for submitting a feature request. Please
be aware that due to the magnitude of change this request requires, it would be
necessary to discuss it on PHP Internals list (internals@lists.php.net) as an
RFC. Please read the guide about creating RFCs here:
<https://wiki.php.net/rfc/howto>. If you haven't had experience with writing
RFCs before, it is advised to seek guidance on the Internals list
(<http://php.net/mailing-lists.php>) and/or solicit help from one of the
experienced developers. 

Please do not consider this comment as a negative view on the merits of your
proposal – every proposal which requires changes of certain magnitude, even the
very successful and widely supported ones, must be done through the RFC process.
This helps make the process predictable, transparent and accessible to all
developers.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 26 11:01:30 2024 UTC