Using the CLI on Linux

Distributions and terminal entry points

Linux does not come in one single edition. Ubuntu, Debian, Fedora, Arch, and other distributions all expose a broadly similar command-line model, but they differ in package managers, release cadence, and some filesystem conventions.

That is why the first Linux CLI mental model should be: the shell experience is stable, while the system-management layer depends on the distro.

On desktop Linux, you usually enter the CLI through a terminal emulator such as GNOME Terminal, Konsole, Alacritty, WezTerm, or Ghostty. On servers, you often begin directly through an SSH session with no graphical interface at all. In both cases, the prompt represents the same underlying system.

# Check current shell
$ echo $SHELL
/bin/bash

# Check distribution information
$ cat /etc/os-release

# Check kernel version
$ uname -a

When you can identify the distro, shell, and current user, you already understand a large part of the Linux operating surface.

Shells and package managers

Most Linux systems still default to Bash, though Zsh, fish, and other shells are common among developers. Bash matters because it is the lowest-common-denominator shell across many tutorials, Docker images, CI jobs, and remote machines.

The second major Linux distinction is the package manager. You do not install tools by downloading random installers most of the time. Instead, you use the distribution's package system.

# Refresh package metadata on Debian/Ubuntu
$ sudo apt update

# Install common tools
$ sudo apt install git curl build-essential

# Search a package
$ apt search tmux

• System packages Use the distro package manager for shell tools, compilers, and base dependencies.

• Language-specific packages Use tools like npm, pip, cargo, or uv on top of the system layer when you are working inside a specific language ecosystem.

Filesystem and permissions

Linux follows a Unix-style filesystem rooted at /. A developer quickly needs to understand home directories, hidden files, executable bits, and ownership.

# View file permissions
$ ls -l deploy.sh
-rwxr-xr-x 1 stone stone 914 Mar 20 09:14 deploy.sh

# Add execute permission
$ chmod +x deploy.sh

# Inspect the current user and groups
$ whoami
$ id

Linux will keep rewarding you for thinking in terms of ownership, group membership, and least privilege. Many "permission denied" errors are not bugs. They are the system reminding you which identity is trying to act on which file or service.

Processes and services

Linux is where many people first learn that the terminal is not only for files. It is also a control plane for long-running processes, daemons, and logs.

# Inspect running processes
$ ps aux | head

# Interactive process viewer
$ top

# Check service state
$ systemctl status ssh

# View recent logs
$ journalctl -u ssh --since today

On many modern distributions, systemd is the service manager. That means systemctl and journalctl become everyday tools for starting services, enabling them at boot, and reading logs after failures.

• Process view Commands like ps, top, htop, and kill help you see what is running and stop it when necessary.

• Service view Commands like systemctl and journalctl help you manage software that stays alive in the background.

SSH and remote work

Linux and SSH are tightly linked. Even if you start on a local desktop machine, many real Linux workflows eventually move onto remote servers, virtual machines, containers, or cloud instances.

# Connect to a remote server
$ ssh user@example.com

# Copy files to a server
$ scp app.tar.gz user@example.com:/srv/app/

# Sync directories efficiently
$ rsync -avz ./dist/ user@example.com:/srv/www/dist/

A practical Linux setup should include SSH key pairs, a basic understanding of ~/.ssh/config, and a habit of verifying where you are before running destructive commands.

# Generate an SSH key
$ ssh-keygen -t ed25519 -C "you@example.com"

# Example SSH config entry
Host my-prod
  HostName prod.example.com
  User deploy
  IdentityFile ~/.ssh/id_ed25519

Developer toolchain

Once the shell, package manager, and permissions model make sense, Linux becomes a very efficient development base. Common next steps include Git, editors, language runtimes, container tooling, and search utilities.

# Common utilities
$ sudo apt install git curl tmux jq ripgrep fd-find

# Git identity
$ git config --global user.name "Your Name"
$ git config --global user.email "you@example.com"

# Check language runtimes
$ python3 --version
$ node --version
$ go version

Many Linux developers also rely on:

1. tmux for persistent terminal sessions.
2. ripgrep and fd for fast codebase search.
3. Docker or Podman for container-based local environments.
4. make, just, or shell scripts for repeatable project tasks.

Linux especially rewards small composable tools. The more repeatable your work becomes, the more the CLI starts to feel like infrastructure rather than a collection of commands.

Productivity habits

A good Linux CLI workflow is not built by memorizing hundreds of commands. It is built through a few repeatable habits.

# Read command manuals
$ man rsync

# Search shell history
$ history | grep docker

# Create a shortcut
$ echo 'alias gs="git status -sb"' >> ~/.bashrc

# Reload shell config
$ source ~/.bashrc

Useful habits to build early:

1. Read the manual before copying random commands.
2. Keep dotfiles and aliases understandable.
3. Prefer scripts for repeated multi-step tasks.
4. Learn to inspect logs before guessing.
5. Use a multiplexer like tmux when sessions need to survive disconnects.

Next steps

Linux becomes much easier once you stop seeing it as "the hard operating system" and start seeing it as a system that exposes its logic more directly through the CLI.

After this tutorial, a strong next path is:

1. Build confidence with package management and permissions.
2. Practice SSH on a local VM or cloud test box.
3. Learn systemctl, logs, and process inspection.
4. Add one repeatable developer workflow using Git, Docker, or shell scripts.

If macOS and Windows tutorials teach you how to use the command line on your own machine, Linux teaches you why the CLI became the shared language of servers, infrastructure, and automation in the first place.