On 07/25/2013 08:42 AM, Ferenc Kovacs wrote:
On Thu, Jul 18, 2013 at 10:38 AM, crankypuss <
[email protected]> wrote:
I've been using PHP for linux command-line applications. Some are quite
large. I've built the code to combine the mainline plus everything it
calls into a single file to avoid portability issues with include
libraries. I've built the code to compress the resulting file using
gzdeflate after optionally stripping comments and excess whitespace.
As a result, I have the uncompressed code in a variable after using
gzinflate. Executing it cleanly has become an issue, and I'm looking for a
solution. I see the following possible solutions:
1. Build the mainline as a function, write the decompressed code to a temp
file, include the temp file, delete the temp file, then invoke the mainline
function. This works reasonably well with the exception that magic
constants like __FILE__ are set during the parsing of the include file.
The result is that for example __FILE__ contains the name of the temp
file, which causes results other than the original. I know of no way to
change __FILE__ once it has been set, and if the application relaunches
using __FILE__ it is attempting to invoke the now-missing temp file.
2. Build the mainline as it was originally coded, write the decompressed
code to a temp file, include the temp file. The problem with this approach
is that if the application issues an exit() the temp file will be left
laying around. Additional issues may exist but this one is imo a
show-stopper.
3. Pass the decompressed code to eval(). This approach is rather a joke
due to the well-intentioned efforts of whoever chose to consider eval() a
security exposure and modified echo to tell the user it is eval'ed code.
Approach (1) seems the most promising but using it will require that the
target applications be specially coded with regard to __FILE__ and possibly
other magic constants. I really don't want to place special requirements
on the coding of the target application.
Suggestions would be appreciated, as I don't want to have to modify the
interpreter at this point. Thanks in advance.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
http://www.php.net/unsub.php
check out
http://us1.php.net/phar and
currently this is the preferred method
for shipping an application in a
single file, as it is allows you to work those files and directories in the
phar via most php functions as those would be normal files/directories on
the disk so stuff like __LINE__ would point a valid path.
The objective is not to perpetuate the idiocy of includes but to obviate it.
for 2, you could use shutdown functions, but with phar:// you wouldn't need
to extract the files, hence no need for the cleanup.
ps: beware, if you try to pass these paths to external libs/application,
they won't be able to work with the phar:// files of course.
Thank you.