Linux and CLI Vocabulary: 35 Essential Terms for the Terminal
Learn 35 essential Linux and command-line terms: shell, stdin/stdout, pipe, process, permissions, file system hierarchy, environment variables, cron, and more.
Linux is the operating system that runs most web servers, cloud infrastructure, and developer tools. Even if you are not a Linux administrator, understanding the command line is essential for deploying applications, debugging issues, and working with containers. This guide covers the 35 most important Linux and CLI terms.
The Shell
Shell
The shell is the program that interprets your commands and communicates with the operating system kernel. Common shells: bash (Bourne Again Shell), zsh (Z shell), fish, sh (POSIX shell).
“Which shell are you using? I’m on zsh with oh-my-zsh.”
Terminal / Terminal Emulator
The terminal (or terminal emulator) is the application that provides a text-based interface to the shell. Examples: iTerm2 (macOS), Windows Terminal, GNOME Terminal (Linux), Alacritty.
Technical note: The terminal is the window; the shell is the program inside it.
Command Line Interface (CLI)
A CLI is a text-based interface where you interact with a program by typing commands. The alternative is a GUI (Graphical User Interface). Most developer tools have both.
Prompt
The prompt is the text the shell displays to indicate it is ready for input. Typically shows your username, hostname, and current directory: user@hostname:~/projects$
Command
A command is an instruction you give to the shell. Anatomy: command [options] [arguments]
Example: ls -la /home/user — ls is the command, -la are flags/options, /home/user is the argument.
Input / Output
stdin, stdout, stderr
The three standard I/O streams every Unix process has:
- stdin (standard input, file descriptor 0) — where a program reads input from (keyboard by default)
- stdout (standard output, file descriptor 1) — where a program writes normal output
- stderr (standard error, file descriptor 2) — where a program writes error messages
Pipe (|)
A pipe connects the stdout of one command to the stdin of another. Lets you chain commands together.
cat access.log | grep "ERROR" | wc -l“Count the number of ERROR lines in the access log.”
Redirect (>, >>, <)
Redirection sends input/output to/from files:
>— overwrite:echo "hello" > file.txt>>— append:echo "world" >> file.txt<— redirect input:wc -l < file.txt2>— redirect stderr:command 2> errors.log
Exit Code
The exit code (or return code) is a number a program returns when it finishes. 0 = success. Any non-zero value = failure. Check with echo $?.
ls nonexistent_file
echo $? # outputs 2 (file not found)Processes
Process
A process is a running instance of a program. Every process has a PID (Process ID).
PID (Process ID)
A unique number assigned to each running process. Use ps, top, or htop to see PIDs.
kill / signal
kill sends a signal to a process. Common signals:
SIGTERM(15) — politely ask the process to stopSIGKILL(9) — forcefully terminate (cannot be caught or ignored)
kill 1234 # SIGTERM to PID 1234
kill -9 1234 # SIGKILL to PID 1234Daemon
A daemon is a background process that runs continuously, typically performing a service role. Examples: nginx (web server daemon), sshd (SSH daemon), cron (job scheduler daemon). Pronounced “DEE-mun.”
Foreground / Background
- Foreground process — runs with the terminal attached (you can see its output; Ctrl+C interrupts it)
- Background process — runs detached:
command &
Use fg to bring a background job to the foreground, bg to continue a stopped job in the background, and jobs to list background jobs.
File System
File System Hierarchy
Linux uses a single root directory /. Key directories:
/etc— configuration files/var— variable data (logs, caches, spool)/home— user home directories/tmp— temporary files (cleared on reboot)/usr— user programs and data/bin,/sbin— essential system binaries/proc— virtual filesystem with process info
Path
Absolute path starts from root: /home/user/projects/app
Relative path starts from current directory: ../config or ./start.sh
Permissions (chmod, chown)
Linux file permissions have three levels: owner, group, others. Each can have read (r), write (w), execute (x) permissions.
-rwxr-xr-- means:
- owner: read, write, execute
- group: read, execute
- others: read only
chmod changes permissions: chmod 755 script.sh or chmod +x script.sh
chown changes ownership: chown www-data:www-data /var/www
Symbolic Link (symlink)
A symlink is a pointer to another file or directory. Similar to a shortcut. Created with ln -s target link_name.
Environment
Environment Variable
Environment variables are key-value pairs available to all processes running in a shell session. Set with export VAR=value. Commonly used for configuration: DATABASE_URL, PORT, NODE_ENV, SECRET_KEY.
“The app reads the database URL from the
DATABASE_URLenvironment variable.”
PATH
The PATH variable is a colon-separated list of directories the shell searches when you type a command. When you type node, the shell searches each PATH directory for an executable named node.
.env file
A .env file stores environment variables for local development. Libraries like dotenv load it into the process environment. Never commit .env to version control — it often contains secrets.
Job Scheduling
cron / crontab
cron is the Unix job scheduler daemon. A crontab (cron table) is a file defining scheduled tasks. The five fields: minute, hour, day-of-month, month, day-of-week.
# Run backup at 2:30 AM every day
30 2 * * * /scripts/backup.shcron expression
A cron expression is the five-field syntax used to define when a job runs. Many cloud services (AWS CloudWatch Events, GitHub Actions, Kubernetes CronJobs) use cron syntax.
Networking from CLI
ssh (Secure Shell)
SSH is a protocol and CLI tool for securely connecting to a remote server. ssh user@hostname opens an encrypted terminal session.
scp / rsync
- scp — securely copy files between local and remote:
scp file.txt user@server:/path/ - rsync — efficient file syncing (only transfers differences):
rsync -avz ./dist/ user@server:/var/www/
curl / wget
- curl — transfer data from URLs; widely used to test APIs:
curl -X POST https://api.example.com/data - wget — download files from URLs:
wget https://example.com/file.zip
Quick Reference
| Term | One-liner |
|---|---|
| Shell | Program that interprets commands (bash, zsh) |
Pipe (|) | Pass stdout of one command to stdin of the next |
| Exit code | 0 = success, non-zero = error |
| Daemon | Background process running as a service |
| PID | Unique number identifying a running process |
| chmod | Change file permissions |
| chown | Change file ownership |
| Environment variable | Key-value configuration available to all processes |
| PATH | Directories searched when you type a command |
| cron | Unix job scheduler; crontab defines schedules |
| ssh | Encrypted remote terminal connection |
| stdin/stdout/stderr | Standard input, output, and error streams |
In Practice: Navigating Nuance for Non-Native Developers
Many developers learning professional English, particularly those transitioning from other technical fields or non-English speaking backgrounds, find the subtleties of command-line communication challenging. It’s not just about knowing what a command does; it’s about understanding how it’s discussed and requested, especially when collaborating with experienced team members. A simple “run this” can be misinterpreted – are you asking for an explanation, a step-by-step guide, or simply the execution of the command? Similarly, feedback in code reviews often employs precise language that requires careful interpretation beyond literal translation. Let’s consider a common scenario: receiving a comment on a pull request.
Imagine you’ve submitted a PR to update a core library function. After review, you receive this message from a senior developer, Sarah: “This is good, but could you add some logging around the data validation? It would help us debug potential issues if they arise.” A direct translation might focus on “logging” – simply adding print statements. However, the phrase “help us debug potential issues” implies a deeper concern. The comment isn’t just requesting output; it’s asking for proactive measures to prevent problems before they occur. This highlights the importance of understanding the underlying intention behind technical requests and feedback. Phrases like “it would help us” frame the request as beneficial, demonstrating an awareness of the team’s needs. It also subtly suggests a potential problem – validating data is perceived as a preventative step.
Furthermore, consider Slack conversations when discussing troubleshooting. A junior developer might type: “The server’s down! Fix it!” This lacks context and could be immediately interpreted as a demand for immediate action without understanding the root cause. A more professional approach would be, “I’m seeing intermittent errors on the production server – specifically, increased latency during peak hours. Could we investigate potential resource constraints or network issues?” The expanded phrasing provides crucial details: the type of problem (intermittent errors), the context (peak hours), and suggests possible areas for investigation. This level of detail is expected in a collaborative environment where clear communication prevents misunderstandings and accelerates resolution times. Learning to articulate technical problems with this precision isn’t just about vocabulary; it’s about demonstrating professional responsibility and contributing effectively to the team.
Finally, pay attention to how commands are described within documentation or commit messages. Often, developers will use phrases like “refactor for clarity” rather than simply stating they’re changing code. This signifies a deliberate effort to improve maintainability and understandability – values highly valued in professional development teams. The goal isn’t just to execute the command itself, but to contribute to a shared understanding of the codebase and its purpose.
# Example: Checking disk space usage on a Linux system
df -hThis simple command, when discussed, might be framed as “Let’s check our disk space utilization to ensure we haven’t exceeded any thresholds.” The added context transforms a basic diagnostic tool into an integral part of a proactive monitoring strategy.