Glossary

Command line

A CLI lets you run project tools through precise commands. It is fast and automatable, but a shell does not forgive misunderstanding the working directory, arguments, or permissions.

Short definition

A text way to give a program a task and its parameters.

Command line can mean a tool interface itself, such as php, git, or docker. A terminal is a window or application that displays text input and output. A shell reads the line and interprets quotes, variables, pipes, redirections, and possible following commands. These words are often mixed in everyday speech, but distinguishing them helps when solving a problem.

An IDE is not a graphical CLI, even when it shows a CLI in an integrated terminal. The php command can launch a runtime, while php bin/console is a specific interface of a Symfony application. The same command on another machine can use another tool version, directory, or environment variables.

What it solves

Repeatable work without clicking through interfaces

A well-named command can be documented, run locally, and checked in CI.

checking repository state and creating a readable Git change
installing and validating PHP dependencies from a lock file
running tests, a linter, static analysis, or a Symfony Console command
controlling local services through Docker Compose
diagnosing configuration and logs in a designated environment

Practical example

Safe checks of a PHP project first

Before a change, a developer checks where they are and whether the repository already contains someone else’s unfinished work. They then run only verification commands. The example does not modify a database, delete files, or install a new package version.

Command output is information. A non-zero exit code means a tool reports a problem; it is not an instruction to repeat the command automatically with more privileges. If a command expects another directory or environment variable, first find out why.

Shell

pwd
git status --short
composer validate --no-check-publish
php bin/console about

How a command runs

From a terminal line to a program result

Text diagram: terminal → shell → command and arguments → process → output and exit code.

Terminal Accepts user text and displays output. It can be standalone or integrated into an IDE.
Shell Interprets syntax such as spaces, quotes, variables, globs, pipes, and redirections. The same text can have a different meaning in another shell.
Command and arguments Launches a program with parameters and a working path. An argument separated by a space is not the same as part of a file name.
Process and permissions The operating system runs the program as a user identity. sudo or an administrator shell changes permissions, not command safety.
Output and exit code A program writes standard output or error output and returns a status. A script and CI can use it to decide the next step.

Practical boundaries

CLI is a common layer for development, checks, and operations.

The command line brings tools together, but does not automatically give them the right context or safe permissions.

IDE

An IDE can open an integrated terminal and start a configuration. Shell behavior and permissions do not change.

Composer and PHP

Composer manages dependencies and php starts a runtime. Each tool has different arguments, output, and impact on a project.

Symfony Console

Application commands are part of the code and can work with a database or integrations, so know the environment before running them.

Docker

Docker CLI controls containers, images, and volumes. A local Docker command need not be safe or available on a production server.

Important concepts

Terminal, shell, and CLI are not synonyms.

Precise names make a problem easier to describe and the right documentation easier to find.

Terminal

A user interface for text input and output. It can start Bash, Zsh, PowerShell, or another shell.

Shell

An operating-system command interpreter. It decides how spaces, variables such as $HOME, wildcards, pipes, and redirections are evaluated.

CLI tools

Programs with their own subcommands and options. git status, composer install, and docker compose are different CLIs with their own documentation.

Working directory

The place from which a command is started. A relative path, configuration, and target file can change with it.

Exit code

The numeric result of a process. Zero usually means success; a non-zero value tells a script and CI to pay attention to an error.

Benefits and limits

Precision and automation in exchange for understanding the syntax.

Benefits

the same process can be documented, repeated, and run in CI
small tools can be composed into one workflow
output and exit code work well for automation
tools often expose more capability than a graphical interface

Risks and mistakes

a command from an unknown source can delete data, run a script, or send secrets
unquoted variables and paths with spaces can change command meaning
sudo increases the impact of a mistake and should not be the first response to permission denied
copying a production command locally, or the reverse, can target different data
quiet redirected output can hide an error or overwrite a file

When it makes sense

Where a team has a describable and repeatable process.

CLI is natural for builds, tests, imports, diagnosis, and version-control work. A command can be simple for a beginner when the project documents its working directory, expected input, safe parameters, and result.

A graphical interface can be more convenient for a one-off task. Even then, it helps to know which command or API operation the button performs. Sensitive production steps also need access control, audit, and an approval process — not only knowledge of a command.

Shell safety

Read an unknown command before running it.

A shell combines data and instructions. A short line can therefore have a larger impact than it appears at first sight.

check the working directory, target environment, and account before a command
do not paste lines with curl, a pipe into a shell, sudo, rm, redirection, or variables without understanding every part
quote paths and values with spaces or special characters correctly for the shell in use
do not put tokens, passwords, or whole environment variables into history, logs, or tickets
try a small harmless sample before a bulk operation and have a backup or recovery path
for team tasks, prefer a versioned script or make target with a clear name over a long undocumented command

Frequently asked questions

Command line without unnecessary risk

Is a terminal the same as a shell?

No. A terminal displays input and output. A shell interprets entered text and launches programs. One terminal can run different shells.

Is a CLI the same as the operating-system command line?

A CLI is a text interface of any program. The operating-system command line is one place from which such CLIs can be launched.

Why not always solve permission denied with sudo?

sudo increases permissions and therefore the consequences of mistakes. First find which file or service is the target and why the normal account has no access.

Is it safe to run a command from a guide I trust?

A trustworthy source helps, but still verify the command in your own context. Check variables, tool version, working directory, conditions, and invisible characters after copying.

How I maintain development quality

I put important procedures into repeatable commands and CI.

For PHP projects, I align builds, quality checks, and operational tasks so they are traceable, verifiable, and independent of clicking through one tool.

How I work with testing and quality Discuss a project without obligation