Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68315
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain m.gmane.org designates 80.91.229.3 as permitted sender)
To: internals@lists.php.net
Date: Fri, 26 Jul 2013 03:49:12 -0600
Lines: 67
Message-ID: <kstgmi$5k7$1@ger.gmane.org>
References: <ks89h7$88f$1@ger.gmane.org> <CAH-PCH7wm0Ga=t1COEH=E=3zRrb8u0ozbwX86dGnC7ZCsTLDWQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
In-Reply-To: <CAH-PCH7wm0Ga=t1COEH=E=3zRrb8u0ozbwX86dGnC7ZCsTLDWQ@mail.gmail.com>
Subject: Re: [PHP-DEV] execute compressed PHP command-line application
From: fullmoon@newsguy.com (crankypuss)

On 07/25/2013 08:42 AM, Ferenc Kovacs wrote:
> On Thu, Jul 18, 2013 at 10:38 AM, crankypuss <fullmoon@newsguy.com> 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

Preferred by whom, thank you very much?  Who is it that has set 
himself/itself up as The Authority on this subject?

> 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.