bin/console
What the bin/console script is, how to find any command with list and about, and the global options every command accepts.
php bin/console [--env=ENV] [-v|-vv|-vvv] [-n] <command> [arguments] [options]Every Symfony project ships a script at bin/console. It is plain PHP. It reads your .env file, builds the kernel (the object that loads your configuration and your classes), and hands that kernel to a console application: an object that holds every command the project knows about, parses what you typed, and runs the one that matches.
Run it with no arguments and you get list, the catalogue of commands grouped by the prefix before the colon. php bin/console about prints the Symfony version, the PHP version, the current environment and the project paths. Any command name followed by --help prints that command's arguments, options and description.
Global options
Some options work on every command. Most have a long form and a short form, and the two forms are the same thing written differently.
| Long | Short | Effect |
|---|---|---|
--env=prod | -e prod | Environment to boot; defaults to APP_ENV |
--verbose | -v | Verbosity 1; repeat the short form for 2 or 3 (-vv, -vvv). The option takes no value, so --verbose=3 is rejected |
--no-interaction | -n | Never ask a question; use defaults |
--quiet | -q | No output, but errors still print |
--silent | none | No output at all, errors included (Symfony 7.2 and later) |
--no-debug | none | Turn debug off; defaults to APP_DEBUG |
Environments
An environment is a named set of configuration: dev for your machine, prod for a server, test for the test suite. APP_ENV in .env sets the default. Passing --env=prod changes it for one run only. Symfony caches each environment separately, so the first prod run on a fresh checkout is slow while that cache is built.
Example
#!/usr/bin/env php
<?php
// bin/console
// This is the whole file. It is ordinary PHP: no magic, just a kernel
// handed to a console application.
use App\Kernel;
use Symfony\Bundle\FrameworkBundle\Console\Application;
if (!is_dir(dirname(__DIR__).'/vendor')) {
throw new LogicException('Dependencies are missing. Try running "composer install".');
}
if (!is_file(dirname(__DIR__).'/vendor/autoload_runtime.php')) {
throw new LogicException('Symfony Runtime is missing. Try running "composer require symfony/runtime".');
}
// Composer's autoloader, plus the runtime that reads .env and builds $context
require_once dirname(__DIR__).'/vendor/autoload_runtime.php';
// The runtime calls this closure. $context holds APP_ENV and APP_DEBUG,
// already resolved from .env and from any --env you passed on the command line.
return function (array $context) {
$kernel = new Kernel($context['APP_ENV'], (bool) $context['APP_DEBUG']);
// FrameworkBundle's Application adds --env, --no-debug and --profile
// on top of the Console component's own global options.
return new Application($kernel);
};When to use it
- Check which environment and which Symfony version a deployed project is actually running.
- Discover whether a bundle you just installed added any commands.
- Re-run a command with -vvv to see the full stack trace behind a one-line error.
More examples
Finding your way around
These four commands are the ones you will type most in the first week. `list` tells you what exists, `--help` tells you how to call it, and `about` tells you which environment you are actually in when a change seems to have no effect. The last two lines are the same command written twice: `-e prod` is shorthand for `--env=prod`. Verbosity has no long form that takes a value, though: `--verbose` is declared with `InputOption::VALUE_NONE`, so `--verbose=3` fails with `The "--verbose" option does not accept a value.` and only `-v`, `-vv` and `-vvv` select a level.
# list every command, grouped by the prefix before the colon
php bin/console
php bin/console list
# only the commands in one group
php bin/console list debug
# versions, environment and project paths
php bin/console about
# what does this command take?
php bin/console cache:clear --help
# command names can be abbreviated while they stay unambiguous
php bin/console c:c # same as cache:clear
# the short and long forms of --env; --verbose is a flag that takes
# no value, so levels 2 and 3 are only available as -vv and -vvv
php bin/console cache:clear -e prod -vvv
php bin/console cache:clear --env=prod -vvvWhere the default environment comes from
`bin/console` resolves `APP_ENV` before the kernel exists, which is why the environment is a global option rather than a per-command one. `--env=prod` overrides the file for a single run; editing `.env.local` changes it for every run on that machine. Setting the variable in the shell works too: `APP_ENV=prod php bin/console about`.
# .env
# Committed to the repository. Holds defaults, never secrets.
APP_ENV=dev
APP_SECRET=change_me
# .env.local
# Not committed. Overrides .env on this machine only.
# APP_ENV=prodThe same thing without the framework
Worth reading once so that `bin/console` stops looking like a black box: an Application is an object, commands are objects you add to it, and `run()` reads `$argv`. In a Symfony project you never write this file, because the framework finds your command classes for you. Reach for it when you want a standalone CLI tool that has no application behind it.
<?php
// bin/standalone-console.php
// The Console component works on its own. This is what bin/console does,
// minus the kernel that loads your configuration.
declare(strict_types=1);
use App\Command\SlugifyCommand;
use Symfony\Component\Console\Application;
use Symfony\Component\String\Slugger\AsciiSlugger;
require __DIR__.'/../vendor/autoload.php';
$application = new Application('My Tools', '1.0.0');
// With no framework there is nothing to build objects for you,
// so you pass the dependencies in by hand.
$application->addCommand(new SlugifyCommand(new AsciiSlugger()));
$application->run();
Discussion