Stanislav Malyshev wrote:
>> Yes, noone hinders you to write PHP_Archieve into your stub when using
>> the Phar extension.
>
> Actually, I would say it would be better to have some "minimized"
> version which is extract-only, has all the comments stripped, etc. for
> inclusion in the archives.
This is extremely easy to do with phar, perhaps this is best done
through documentation? Such a script would be extremely short and would
definitely be cut-and-pasteable, for instance:
<?php
$here = dirname(__FILE__) . DIRECTORY_SEPARATOR . basename(__FILE__,
'.phar');
mkdir($here);
foreach (new RecursiveIteratorIterator(
new RecursiveDirectoryIterator('phar://' . __FILE__)) as $path
=> $unused) {
$newpath = $here . DIRECTORY_SEPARATOR . str_replace('/',
DIRECTORY_SEPARATOR,
str_replace('phar://' . __FILE__ . '/', '', $path));
if (!file_exists(dirname($newpath))) mkdir(dirname($newpath), 0664,
true);
copy($path, $newpath);
}
__HALT_COMPILER();
Setting the stub is really easy:
$phar->setStub($code);
where $code contains the stuff above as a string, or as an open file
pointer to the file stub. The minimal script might want to instead use
$argv[1] or even display a web form, depending on the context - this is
the primary reason we didn't hard-code a massive stub. By default, the
stub created by making a phar is designed for a minimal non-extract
library, but phar is designed with enough flexibility that is is not
just easy but remarkably simple to do extremely complex stuff with the
stub or with the contents. In fact, it is much easier than either
PHP_Archive or PHK, and this is a direct result of features that are not
possible with a userspace stream. One can argue over their utility but
the original reason behind making PHP_Archive into an extension is no
longer the only reason.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
