Home / Glossary / CLI (Command-Line Interface)
Tech & ITCLI (Command-Line Interface)
By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site
A text interface where you control a program by typing commands instead of clicking.
With a CLI you type a command such as git push or curl, add options, and read text output. It matters at work because servers often have no screen, and commands can be scripted, repeated exactly and run by continuous integration (CI) pipelines. Beginners mix up three words: the terminal is the window, the shell (bash, zsh or PowerShell) interprets what you type, and the CLI is the interface a program offers.
The intuition
A command-line interface is a program you control by typing. You name the program, add a subcommand and some options, press Enter, and read text back: git log --oneline -5, aws s3 ls, python3 run_pnl.py --date 2026-09-30. Nothing is hidden behind a button, so what you did can be written down exactly, copied into a script, put in a scheduler and run again tomorrow by a machine. That reproducibility is why servers, pipelines and continuous integration all speak the command line, and why graphical tools usually expose a CLI underneath.
The picture to hold is three layers. The terminal is the window that displays text and takes keystrokes. The shell, bash or zsh on macOS and Linux, PowerShell on Windows, is the program inside that window that reads your line, expands wildcards and variables, and launches whatever program you named. The CLI is the interface each of those programs offers: git's subcommands, pip's options, the aws tool's hundreds of commands. When something fails, knowing which layer failed, a shell typo, a missing program or a wrong option, is half the diagnosis.
Most CLIs follow conventions that make a new one quick to learn. tool --help lists the commands, tool command --help explains one, and tool --version says what is installed. Options come as --long-name or short -x flags, and arguments without a dash are the things to act on. Output goes to standard output and errors to standard error, and the program ends with an exit code, 0 for success and anything else for failure, which is what a scheduler or a pipeline checks to decide whether the nightly job worked.
Example
# ask a CLI which version it is git --version # a subcommand with two options git log --oneline -5 # -i shows the response headers, then the page curl -i https://example.com # most CLIs document their own options python3 --help
Running the nightly P&L job by hand from the command line, then handing it to the scheduler
- A data engineer needs to rerun yesterday's P&L for one desk after a late trade correction. Open a terminal, move to the project: cd ~/pnl-jobs. Check the tool exists and which version it is: python3 --version prints Python 3.12.4, and python3 run_pnl.py --help prints the usage: run_pnl.py [--date YYYY-MM-DD] [--desk NAME] [--dry-run].
- Rehearse: python3 run_pnl.py --date 2026-09-30 --desk rates --dry-run. The job reads 3,418 trades, prices them, and prints the totals it would write without writing anything. The --dry-run option exists for exactly this moment.
- Run for real: python3 run_pnl.py --date 2026-09-30 --desk rates. It prints Wrote 3418 rows for rates on 2026-09-30 and exits. Check the exit code with echo $? (bash or zsh): 0 means success. Had the database been unreachable, the job would print a traceback to standard error and exit with 1.
- Chain commands: python3 run_pnl.py --date 2026-09-30 --desk rates && python3 send_report.py --desk rates. The && means the second command runs only if the first succeeded, because the shell reads the exit code; a failed P&L never triggers an email with stale numbers.
- Capture the output for the audit trail: python3 run_pnl.py --date 2026-09-30 --desk rates > logs/pnl-rates-2026-09-30.log 2>&1 sends standard output to the file and, through 2>&1, standard error to the same file. The log is the record of what ran.
- Hand it to the machine: the same line, with the date generated by the scheduler, becomes the nightly job in cron or in the firm's orchestrator. What goes wrong first time: the scheduler's environment lacks the DATABASE_URL variable the engineer had exported in her shell, and the job fails at 02:00 with KeyError. The variable is added to the scheduler's configuration; the command itself never changed.
A command line turns a task into a line of text with options, an exit code and captured output, so what you ran by hand at your desk is exactly what the scheduler runs at 02:00, with its environment variables set explicitly.
Common pitfalls
- Ignoring the exit code: a pipeline that does not check it treats a crashed job as a success and sends downstream reports on missing data.
- Confusing terminal, shell and CLI, then installing the wrong fix: a command not found error is the shell failing to locate a program, not a bug in the program.
- Running a destructive command without a rehearsal: use --dry-run or a listing command first, especially with tools such as rm -rf, aws s3 rm or git push --force.
- Depending on interactive shell state: variables exported and directories changed in your session do not exist for cron, so a job that works by hand fails at night.
- Pasting commands from the internet without reading them: a one-liner can download and execute arbitrary code; read it, or run it in a test machine first.
Frequently asked questions
What is a CLI in simple terms?
A way to use a program by typing commands rather than clicking. You type the program's name with options and arguments, such as git status or pip install pandas, and it prints text back. CLIs are precise and scriptable, which is why servers without screens, automation pipelines and schedulers rely on them.
What is the difference between a terminal, a shell and a CLI?
The terminal is the window that shows text and accepts keystrokes. The shell, such as bash, zsh or PowerShell, is the program running in it that interprets what you type and launches other programs. A CLI is the command-line interface a particular program offers, such as git's subcommands. You use a terminal to talk to a shell to drive a program's CLI.
Why do data and finance teams use the command line?
Because a command is reproducible: the exact line that ran the P&L job today can run it tomorrow, be reviewed in a script, checked into Git and executed by a scheduler. Graphical tools cannot easily be automated or audited that way. Cloud tools, Git, package managers and most data platforms are built CLI-first for the same reason.
What does an exit code mean?
A number a program returns when it finishes: 0 for success, anything else for failure. The shell exposes it as $? and uses it in constructs such as command1 && command2, which only runs the second if the first succeeded. Schedulers and CI pipelines rely on exit codes to decide whether a step passed, so a script should exit non-zero on any error.