Re: execute compressed PHP command-line application
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
http://www.php.net/manual/en/wrappers.phar.php
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.
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.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Thread (11 messages)