PHPackages                             kael-shipman/php-executables - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. kael-shipman/php-executables

AbandonedArchivedLibrary[Utility & Helpers](/categories/utility)

kael-shipman/php-executables
============================

A set of small, abstract executable classes and peripherals

v0.6.0(7y ago)036[5 issues](https://github.com/kael-shipman/php-executables/issues)1MITPHP

Since Jan 12Pushed 6y ago1 watchersCompare

[ Source](https://github.com/kael-shipman/php-executables)[ Packagist](https://packagist.org/packages/kael-shipman/php-executables)[ RSS](/packages/kael-shipman-php-executables/feed)WikiDiscussions master Synced yesterday

READMEChangelogDependencies (2)Versions (14)Used By (1)

PHP Executables
===============

[](#php-executables)

> **ABANDONED**
>
> This was sorta fun while it lasted, but there's absolutely no reason to do executables in PHP vs Go or Typescript. If anyone's still interested in this, feel free to take it over, but I've moved on.

There seem to be a handful of attempts at making daemonizing easy in PHP. I haven't looked deeply into these, so I'm not sure I'm really contributing much to the community by adding yet another one, but I have a selfish interest in trying it anyway.

This library contains classes for creating general executables. I define an executable as an application that can be called on the command line, usually with command-line arguments. That application may be a daemon, which runs in the background until it is killed, or it may be a single-run worker application that does a job and exits.

The main features of any of these are the following:

1. Easy handling of command-line arguments
2. A standard way of handling multi-channel logging
3. A standard and easy way to parallel process

None of these are particularly difficult tasks. Because of that, it's not clear exactly how much is to be gained by using a framework like this. At the same time, if you build a lot of applications, it makes sense to build them all in the same way, and thus it makes sense to use a (small) framework that fulfills these requirements in way you're happy with.

Basic Assumptions
-----------------

[](#basic-assumptions)

The primary basic assumption here is that your runtime application code should be separate from your functional library. Thus, any extensions of the classes in these libraries should implement little more than the code necessary to initialize functional dependencies and distribute the command to them. They should also maintain communication with the user and logs via interaction through the standard channels defined in this library.

Usage
-----

[](#usage)

To create an executable, you'll need to include this library as a composer dependency in your project, then create at least 2 files.

The first is the actual entry point -- a bootstrap file, the equivalent of an `index.php` in the web world. That will handle all your configuration logic, including commandline arguments, etc., which you can do however you wish (though I would recommend [commando](https://github.com/nategood/commando)).

Next, you'll need to create a class that extends one of the abstract classes in this library. That class will be your actual runtime application, whose `run` method should be called by your bootstrap file. It should all look something like this:

**Bootstrap file:**

```