I've noticed a recurring pattern with people starting out in PHP: they assume that if they aren't seeing a page in Chrome or Firefox, PHP isn't actually "running." There is this deep-seated belief that PHP is a "website language" and therefore requires a web server like Apache or Nginx to breathe. If you've spent your first few lessons refreshing a browser tab to see changes, you're probably leaning into this misconception.

The myth: "I need a web server to execute PHP"

If you believe you need a server, you're likely thinking of PHP as a tool that only responds to HTTP requests. But PHP is actually a general-purpose scripting language. It just happens to be incredibly good at web work. To prove this, look at this script. I've written a simple tool that checks if a specific configuration file exists on the system—something a web browser doesn't need to know about.

<?php
$filename = 'config.ini';
if (file_exists($filename)) {
    echo "System Check: $filename found. We are good to go!\n";
} else {
    echo "System Check: $filename is missing. Please check the installation.\n";
}
?>

If you try to run this via a browser, you're dealing with overhead: the web server receives the request, hands it to the PHP engine, and then sends the output back over HTTP. But if you have PHP installed on your machine, you can bypass all that. You just open your terminal and type php config_check.php. The output appears instantly in your console. No ports, no URLs, no browser caching issues. Just raw execution.

The reality: Using the CLI for automation and tooling

Running PHP from the Command Line Interface (CLI) is where the real power lies for a developer. I use the CLI constantly for things that would be a nightmare to do in a browser—like running database migrations, clearing caches, or processing huge CSV imports that would time out if run through a web server.

When you run a script via the CLI, PHP uses a different "SAPI" (Server API). This means you get a few perks. For one, the max_execution_time limit is usually disabled by default in the CLI. You can run a script for ten hours if you need to, and it won't "timeout" like a webpage would. I've spent plenty of late nights running long-running data cleanup scripts that would have crashed any web server I tried to route them through.

Interacting with your scripts via $argv

One of the biggest shifts in mindset when moving to the CLI is how you get data into your script. In a browser, you use $_GET or $_POST. In the terminal, you use $argv.

$argv is an array containing all the arguments passed to the script. The first element ($argv[0]) is always the name of the script itself. Everything after that is a custom argument. Here is a quick example of a script that greets a user specifically by the name passed in the terminal:

<?php
// Usage: php greet.php Sarah
if (isset($argv[1])) {
    echo "Hello, " . $argv[1] . "! Welcome to the terminal.\n";
} else {
    echo "You forgot to provide a name!\n";
}
?>

If you run php greet.php Sarah, the output is "Hello, Sarah!". This allows you to build tools that are dynamic and flexible without ever needing to build a UI for them. Once you get comfortable with this, you'll realize that the terminal is actually your most efficient workspace.

📋 Practical Task

Build a Basic Directory File-Counter

Your task is to create a PHP script that runs exclusively from the command line. The script should accept a directory path as an argument and print the total number of files located in that directory.

Requirements:

• The script must use $argv to retrieve the folder path from the user.
• If no path is provided, the script should print a usage message: Usage: php count_files.php [folder_path].
• Use the scandir() function to read the directory.
• Ensure the script filters out the current directory (.) and parent directory (..) so they aren't counted as files.
• The final output should be a simple string: The directory [path] contains [X] files.

Testing your work:
Run it in your terminal: php count_files.php /path/to/your/folder