start here

Interactive Shell

PHP can run small snippets without creating a full script file. That is useful when you want to inspect one runtime value, test a standard-library function, check a date format, or prototype a small helper before adding it to the project.

The interactive shell is not a replacement for tests or application code. It is a quick feedback tool.

`php -a`

php -a starts PHP's interactive shell when your PHP build supports it.

php -a

Inside the shell, type PHP statements and press Enter:

php > echo PHP_VERSION . PHP_EOL;
8.5.6
php > var_dump(extension_loaded('mbstring'));
bool(true)

You do not type <?php inside php -a. You are already in PHP mode.

`php -r`

php -r runs a short snippet from the command line and exits. It is often more convenient than opening the interactive shell.

php -r "echo PHP_VERSION . PHP_EOL;"
php -r "var_dump(extension_loaded('intl'));"
php -r "echo ini_get('memory_limit') . PHP_EOL;"

Use php -r for one-off checks. Use a script file when the code grows beyond one or two lines.

Checking Runtime Values Quickly

The shell is useful for proving which settings are active in the current CLI runtime.

PHP example

<?php

declare(strict_types=1);

echo 'PHP: ' . PHP_VERSION . PHP_EOL;
echo 'SAPI: ' . PHP_SAPI . PHP_EOL;
echo 'memory_limit: ' . ini_get('memory_limit') . PHP_EOL;
echo 'Loaded ini: ' . (php_ini_loaded_file() ?: 'none') . PHP_EOL;

// Prints:
// PHP: 8.5.6
// SAPI: cli
// memory_limit: 128M
// Loaded ini: /etc/php.ini

If a web request behaves differently, do not assume php -a proves the web runtime. CLI and FPM can load different configuration.

Testing Small Standard-Library Behaviour

The shell is excellent for checking exact PHP behaviour before you write code.

php -r "var_dump(filter_var('ada@example.com', FILTER_VALIDATE_EMAIL));"
php -r "echo json_encode(['name' => 'Ada'], JSON_THROW_ON_ERROR) . PHP_EOL;"
php -r "echo (new DateTimeImmutable('tomorrow'))->format('Y-m-d') . PHP_EOL;"

This is useful when you are not sure about return values, date formatting, JSON flags, string functions, or extension availability.

Prototyping A Helper

When a snippet becomes useful, move it into a named function and then into a real file.

PHP example

<?php

declare(strict_types=1);

function normaliseCliName(string $name): string
{
    $name = trim($name);
    $name = preg_replace('/\s+/', ' ', $name) ?? '';

    return ucwords(strtolower($name));
}

echo normaliseCliName("  ADA   LOVELACE  ") . PHP_EOL;

// Prints:
// Ada Lovelace

The shell helps you discover the shape of the code. The finished helper belongs in the application with tests or at least a small command-level check.

Framework Shells

Many frameworks provide richer shells:

Laravel has Tinker
Symfony projects often use Console commands
PsySH can be installed as a standalone REPL

Framework shells can boot the application container, models, configuration, and services. That makes them powerful, but also risky in production. Be careful with commands that write to the database, dispatch jobs, send emails, or call external services.

What Not To Do In A Shell

Avoid using an interactive shell for:

unreviewed production data changes
destructive database operations
scripts that need repeatability
code that should be committed and reviewed
checks where the web SAPI is the thing being debugged

If a command matters enough to repeat, turn it into a script, test, migration, or framework command.

What You Should Be Able To Do

After this lesson, you should be able to use php -a and php -r, inspect runtime values, test small PHP behaviours, and decide when a snippet should become a real script.

For junior PHP work, this matters because quick investigation is part of debugging. The professional habit is to use the shell for fast learning, then move durable work into code that can be reviewed.

Practice

Practice: Try `php -r`

Use php -r to run three one-line runtime checks.

Task

Run commands that print:

PHP_VERSION
whether mbstring is loaded
the current memory_limit

Then write a short note explaining what each command proved.

Keep the commands and example output in code blocks. If your output differs because your machine has a different version or configuration, note that difference.

Show solution

These commands prove facts about the CLI runtime.

php -r "echo PHP_VERSION . PHP_EOL;"
php -r "var_dump(extension_loaded('mbstring'));"
php -r "echo ini_get('memory_limit') . PHP_EOL;"

Example output:

8.5.6
bool(true)
128M

The first command proves which PHP version the shell runs. The second proves whether the mbstring extension is loaded in CLI PHP. The third proves the active CLI memory limit.

Task: Check Runtime Value

Create a short diagnostic snippet for checking the current CLI runtime.

Requirements

Build a snippet that prints:

PHP_VERSION
PHP_SAPI
php_ini_loaded_file()
APP_ENV

Use strict types. Keep example output in the PHP code block as comments.

Afterward, add a short note explaining why this does not automatically prove the PHP-FPM web runtime has the same configuration.

Show solution

This snippet gives a compact view of the current CLI runtime.

PHP example

<?php

declare(strict_types=1);

$loadedIni = php_ini_loaded_file();
$appEnvironment = getenv('APP_ENV');

echo 'PHP: ' . PHP_VERSION . PHP_EOL;
echo 'SAPI: ' . PHP_SAPI . PHP_EOL;
echo 'Loaded ini: ' . ($loadedIni === false ? 'none' : $loadedIni) . PHP_EOL;
echo 'APP_ENV: ' . ($appEnvironment === false ? 'not set' : $appEnvironment) . PHP_EOL;

// Prints:
// PHP: 8.5.6
// SAPI: cli
// Loaded ini: /etc/php.ini
// APP_ENV: not set

This does not automatically prove the PHP-FPM web runtime has the same configuration. CLI and FPM can use different SAPIs, users, environment variables, loaded php.ini files, and enabled extensions.

Task: Prototype Helper

Prototype a small helper that normalises a human name, then show the finished version as a real function.

Requirements

Build a function that:

trims leading and trailing whitespace
collapses repeated whitespace inside the name
lowercases the value
converts it to title case

Use strict types. Keep the expected output inside the PHP code block as comments.

Afterward, add a short note explaining when a shell experiment should become a committed helper function.

Show solution

This solution shows the helper after the shell experiment has become real code.

PHP example

<?php

declare(strict_types=1);

function normaliseHumanName(string $name): string
{
    $name = trim($name);
    $name = preg_replace('/\s+/', ' ', $name) ?? '';

    return ucwords(strtolower($name));
}

echo normaliseHumanName("  ADA   LOVELACE  ") . PHP_EOL;
echo normaliseHumanName("grace\tHOPPER") . PHP_EOL;

// Prints:
// Ada Lovelace
// Grace Hopper

A shell experiment should become a committed helper when it will be reused, reviewed, tested, or run by someone else. The shell is for discovery; durable behaviour belongs in project code.