Home  >  Article  >  Backend Development  >  A brief analysis of the correct method of calling system commands in PHP applications

A brief analysis of the correct method of calling system commands in PHP applications

青灯夜游
青灯夜游forward
2022-12-19 19:41:504918browse

A brief analysis of the correct method of calling system commands in PHP applications

Sometimes you need to use operating system level commands in your PHP application. Let's look at how we do this and see if we can make the developer experience better.

Over the past few years I have been focusing on every aspect of how I write code and how to improve it. I started by looking into how to make the integration with HTTP better and more object-oriented. I believe I found a way to achieve this and now I'm focusing my attention elsewhere. [Related recommendations: laravel video tutorial]

In some cases, you want to use the OS CLI in your application. In a web application or another CLI application. In the past, we have used methods like exec or passthru or shell_exec and system. Then along came the Symfony Process component and we were saved.

The Symfony process component makes it very easy to integrate with operating system processes and obtain output. But how we integrate with this library is still a bit frustrating. We create a new process, passing in an array of arguments for the command we wish to run. Let’s take a look:

$command = new Process(
    command: ['git', 'push', 'origin', 'main'],
);

$command->run();

What’s wrong with this approach? Well, honestly, nothing. But is there a way to improve the developer experience? Let's say we switch from git to svn (which I'm unlikely to know).

To improve the developer experience, first, we need to understand the components that are logically used to create OS commands. We can break them down into:

  • Executable
  • Parameters

Our executable is something we interact with directly, e.g. php, git, brew or any other installed binary on our system. The argument then is how we interact; these can be subcommands, options, flags or parameters.

So if we abstract a little bit, we have a process and a command, which takes arguments. We will use interfaces/contracts to define our components to control how our workflow should work. Let's start with the process contract:

declare(strict_types=1);

namespace JustSteveKing\OS\Contracts;

use Symfony\Component\Process\Process;

interface ProcessContract
{
    public function build(): Process;
}

What we are saying here is that every process must be able to be built, and the result of the created process should be a Symfony process. Our process should build a command for us to run, so now let's look at our command contract:

declare(strict_types=1);

namespace JustSteveKing\OS\Contracts;

interface CommandContract
{
    public function toArgs(): array;
}

The main thing we want from the command is to be able to return it as parameters, which we can pass as The command is passed to the Symfony process.

Enough with the ideas, let’s look at a real-life example. We'll use git as an example since most of us should be able to relate to the git command.

First, let's create a Git process to implement the Process Contract we just described:

class Git implements ProcessContract
{
    use HandlesGitCommands;

    private CommandContract $command;
}

Our process implements the contract and has a command attribute that we will use to allow our Processes are structured and executed smoothly. We have a feature that allows us to focus on the way we build and make things for our Git process. Let's take a look:

trait HandlesGitCommands
{
    public function build(): Process
    {
        return new Process(
            command: $this->command->toArgs(),
        );
    }

    protected function buildCommand(Git $type, array $args = []): void
    {
        $this->command = new GitCommand(
            type: $type,
            args: $args,
        );
    }
}

So our trait shows the implementation of the process contract itself and provides instructions on how to build the process. It also contains a method that allows us to abstract the build command.

So far we can create a process and build a potential command. However, we have not given the order yet. We create a new Git command in the trait, using the Git class as the type. Let's look at another Git class, which is an enumeration. However, I'll show a stripped down version - essentially, you want it to map to all the git subcommands you wish to support:

enum Git: string
{
    case PUSH = 'push';
    case COMMIT = 'commit';
}

Then we pass it to the Git command:

final class GitCommand implements CommandContract
{
    public function __construct(
        public readonly Git $type,
        public readonly array $args = [],
        public readonly null|string $executable = null,
    ) {
    }

    public function toArgs(): array
    {
        $executable = (new ExecutableFinder())->find(
            name: $this->executable ?? 'git',
        );

        if (null === $executable) {
            throw new InvalidArgumentException(
                message: "Cannot find executable for [$this->executable].",
            );
        }

        return array_merge(
            [$executable],
            [$this->type->value],
            $this->args,
        );
    }
}

in In this class, we accept parameters from Process, currently handled by our HandledGitCommands trait. We can then turn this into a parameter that the Symfony process can understand. We use ExecutableFinder from the Symfony package to minimize errors in the path. However, we also want to throw an exception if the executable is not found.

When we put them in our Git process, it looks a little like this:

use JustSteveKing\OS\Commands\Types\Git as SubCommand;

class Git implements ProcessContract
{
    use HandlesGitCommands;

    private CommandContract $command;

    public function push(string $branch): Process
    {
        $this->buildCommand(
            type: SubCommand:PUSH,
            args: [
                'origin',
                $branch,
            ],
        );

        return $this->build();
    }
}

Now all that's left to do is run the code itself so that we can run it in the PHP application Nice use of git in your program: The result of the

$git = new Git();
$command = $git->push(
    branch: 'main',
);

$result = $command->run();

Push method will allow you to interact with the symfony process - meaning you can perform all the sorting using commands on the other end. The only thing we changed was to build an object-oriented wrapper around the creation of this process. This allows us to develop and maintain the context well and extend things in a testable and scalable way.

How often do you use operating system commands in applications? Can you think of any use cases? I've published the sample code in a repository on GitHub so that you can play with it and see if you can improve your operating system integration.

A good example would be SSH, MySQL, or even Anable or Terraform! Imagine if you could efficiently run MySQL dumps from Laravel Artisan on a schedule without having to use third-party packages all the time!

Original address: https://laravel-news.com/working-with-os-process-in-php

Translation address: https://learnku.com/ laravel/t/71422

For more programming-related knowledge, please visit: Programming Video! !

The above is the detailed content of A brief analysis of the correct method of calling system commands in PHP applications. For more information, please follow other related articles on the PHP Chinese website!

Statement:
This article is reproduced at:learnku.com. If there is any infringement, please contact admin@php.cn delete