Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68151
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <ks89h7$88f$1@ger.gmane.org>
References: <ks89h7$88f$1@ger.gmane.org>
Date: Thu, 18 Jul 2013 18:05:55 +0900
Message-ID: <CAGa2bXYRL33scD6fpnbcnOkNddmkkjxf0-LPiSGYCfNQ=jqN2g@mail.gmail.com>
To: crankypuss <fullmoon@newsguy.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae93d8edef88a0504e1c586f5
Subject: Re: [PHP-DEV] execute compressed PHP command-line application
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--14dae93d8edef88a0504e1c586f5
Content-Type: text/plain; charset=ISO-8859-1

Hi,

You may use register_shutdown_function() to clean things up after exit()

http://jp2.php.net/manual/en/function.register-shutdown-function.php

So simply extract files to tmp dir and delete everything after execution.
I guess this is what you need.

BTW, I don't think eval() is evil as long as programmers know what they
are doing.

Regards,


--
Yasuo Ohgaki
yohgaki@ohgaki.net


2013/7/18 crankypuss <fullmoon@newsguy.com>

> 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
>
>

--14dae93d8edef88a0504e1c586f5--