How to Install Software from the Command Line (Windows, macOS, and Linux)

You typed the wrong thing into Command Prompt once, got a wall of red text, and closed it. Fair. Most people’s first brush with trying to install software command line style goes that way. But once you get past the first successful install, it’s genuinely faster than clicking through setup wizards — and it’s the only realistic option once you’re managing more than a couple of machines.

To install software from the command line, you use a package manager: winget install <app> on Windows, brew install <app> on macOS, or sudo apt install <app> on Debian-based Linux. Each tool downloads the package, resolves dependencies, and installs it automatically, without a GUI installer.

This guide covers the real commands for each operating system, how to check that an install actually worked, how to fix the errors that trip people up most, and how to do it safely.

What Does It Mean to Install Software from the Command Line?

A GUI installer walks you through screens: choose a folder, accept a license, click Next a few times. A command-line install skips all of that. You type one line, hit Enter, and a package manager does the rest.

A package manager is a tool that fetches software from a repository — a server that hosts packages — checks what other software your requested app depends on (this is called dependency resolution), downloads everything in the right order, and puts the files where they belong. It also keeps a record of what’s installed, which is why updating or removing software later is just as simple as installing it.

Every major OS has its own default tool for this, and most have two or three competing options. That’s really the whole story of this article: which command, on which system, for which job.

Quick takeaway: command-line installs aren’t a “power user trick” — they’re the standard workflow for developers and IT admins because they’re scriptable, repeatable, and don’t require you to babysit a wizard.

Installing Software on Windows: winget, Chocolatey, and Scoop

Windows has three realistic command-line paths, and they solve slightly different problems.

Using winget (the built-in option)

Windows Package Manager, or winget, ships built into Windows 10 and Windows 11 — no separate install needed. It pulls from a Microsoft-curated source plus the Microsoft Store catalog.

1. Open Start, search for Terminal or PowerShell, and pick “Run as administrator.”
2. Search for the app you want:

   winget search "Visual Studio Code"

3. Install it by name or ID:

   winget install --id Microsoft.VisualStudioCode -e

The -e flag means “exact match,” which avoids accidentally installing the wrong similarly-named package.

winget is the right default for most people. It’s already there, Microsoft vets what’s in it, and it handles both traditional desktop apps and Microsoft Store apps.

Using Chocolatey

Chocolatey predates winget by close to a decade and has a much larger community package repository, built on NuGet packaging. If winget doesn’t have an app, Chocolatey often does.

choco install gimp

That single line downloads GIMP, verifies it, and installs it with no dialog boxes. Chocolatey does need to be installed itself first (a one-time PowerShell script from the official site), and most package installs require administrator rights.

Using Scoop

Scoop takes a different approach: it installs into your user folder instead of system-wide, so most installs don’t need admin rights at all. It’s popular with developers who want a clean, portable set of command-line tools rather than full desktop applications.

scoop install git

Quick takeaway: use winget for everyday apps, Chocolatey when you need a package winget doesn’t carry or you’re scripting deployments across many machines, and Scoop when you want lightweight CLI tools without touching admin permissions.

Installing Software on macOS with Homebrew

macOS doesn’t ship with a package manager, which is exactly the gap Homebrew fills — its own tagline calls it the missing package manager for macOS.

Before you can use it, macOS needs the Xcode Command Line Tools (a small set of compiler and build tools). Homebrew’s installer prompts you to install these automatically the first time you run it.

Once Homebrew is set up, installing anything is one line:

brew install wget

For full desktop applications rather than command-line tools, Homebrew has a separate “cask” system:

brew install --cask visual-studio-code

Homebrew downloads the package, checks its dependencies, and places binaries in a predictable location that’s already on your shell’s PATH — so the moment the install finishes, the command is ready to use.

Installing Software on Linux: apt, dnf, pacman, and Nix

Linux is where package managers actually originated, and which one you use depends entirely on your distribution family.

Debian and Ubuntu (apt/dpkg)

Debian, Ubuntu, and Mint all use .deb packages managed by dpkg under the hood, but almost nobody calls dpkg directly. Instead, you use apt, which also handles fetching from repositories and resolving dependencies:

sudo apt update
sudo apt install neofetch

Running apt update first refreshes the local list of available package versions — skipping it is the most common reason installs silently grab an outdated version.

Fedora, CentOS, and Red Hat (dnf/yum)

Red Hat–family distributions use .rpm packages. Modern systems use dnf; older ones use its predecessor, yum, which dnf was built to replace:

sudo dnf install htop

Arch Linux (pacman) and Nix

Arch Linux uses its own tool, pacman:

sudo pacman -S neovim

And across distributions — even alongside apt or dnf — you’ll increasingly see Nix, which takes a declarative approach: you describe the exact package and version you want in a config, and Nix builds a reproducible environment from it. It’s popular for teams that need identical setups across many machines.

Quick takeaway: always match the tool to the distribution family. Running an apt command on Fedora, or a dnf command on Ubuntu, will simply fail — they’re not interchangeable.

Verifying, Updating, and Uninstalling Software

Installing is only half the workflow. Every package manager has a matching command to confirm, update, and remove software — and skipping this step is why people end up with duplicate or orphaned installs.

Action	Windows (winget)	macOS (Homebrew)	Linux (apt)
Check if installed	winget list	brew list	apt list --installed
Update one app	winget upgrade <app>	brew upgrade <app>	sudo apt install --only-upgrade <app>
Update everything	winget upgrade --all	brew upgrade	sudo apt upgrade
Uninstall	winget uninstall <app>	brew uninstall <app>	sudo apt remove <app>

Running the “check if installed” command before you install anything is a habit worth building — it avoids duplicate installs and tells you immediately whether a previous attempt actually succeeded.

Fixing Common Command-Line Install Errors

Almost every install failure falls into one of four buckets.

1. “Command not found” right after installing. The app installed, but its location isn’t on your shell’s PATH environment variable yet. Close and reopen your terminal — most package managers update PATH on install, but the current session doesn’t see the change until it restarts.
2. Permission denied. Windows and Linux package managers that install system-wide need elevated rights — run Terminal/PowerShell “as administrator” on Windows, or prefix Linux commands with sudo. Scoop and Homebrew are exceptions since they install to your user account.
3. Dependency conflicts. A package needs a version of a library that clashes with something already installed. On Linux, running sudo apt --fix-broken install (or the dnf/pacman equivalent) usually resolves it by realigning versions.
4. Package not found. Either the name is slightly off (check with the manager’s search command first) or the repository list is stale — run the update command before installing.

Quick takeaway: most install errors aren’t really about the software you’re installing — they’re PATH, permissions, or a stale repository list. Rule those out first.

Installing Multiple Apps and Automating Setup

Once you’re comfortable with single installs, chaining them saves real time on a new machine setup.

Windows (winget):

winget install --id Git.Git -e && winget install --id Microsoft.VisualStudioCode -e

macOS/Linux (works the same way in Bash or Zsh):

brew install git node python

For unattended, no-prompt installs — common in IT deployment scripts — most Windows installers and package managers support a silent install flag (often /silent or /quiet for standalone .exe files, and -y or --yes for package managers) that skips every confirmation prompt. This is also how remote installs to other machines on a network typically work: the same commands are run against a target computer instead of the local one, usually inside a deployment script or remote session.

Is It Safe? Security Best Practices

Command-line installs run with real system permissions, so a little caution goes a long way.

• Stick to official repositories (the default winget, Homebrew, apt, or dnf sources) rather than adding random third-party ones you found in a forum post.
• Don’t pipe unknown scripts straight into your shell. A command like curl <url> | bash runs a script you haven’t read with full user permissions — check what it does first, or download and inspect it before running.
• Package managers already check integrity for you via checksums and, on Windows, code signing — that’s part of why using the manager beats manually downloading an .exe from a random mirror site.
• Only grant admin/sudo rights when the tool actually needs them. If a package manager doesn’t ask for elevation, that’s usually a sign it’s installing safely to your user account.

None of this is exotic advice — it’s the same “trust the source” logic you’d apply to any download, just applied to a command instead of a browser click.

READ MORE: How to Choose Antivirus Software (Without Falling for Marketing Claims)

Wrapping Up

The command itself is almost always short — winget install, brew install, sudo apt install — followed by a package name. The part that actually matters is knowing which tool belongs to which system, checking that the install landed before you move on, and having a mental checklist for the handful of errors that account for nearly every failure. Once that’s second nature, reinstalling your entire toolkit on a fresh machine is a five-minute job instead of an afternoon of clicking through installers.

If you’re setting up a new machine, start with your OS’s built-in tool — winget, or apt if you’re on Ubuntu — and only add Chocolatey, Scoop, or Homebrew casks once you hit something the default can’t find.

NEED MORE ANSWERS? CHECK OUT MORE GUIDES FOR MORE FREE SOFTWARE GUIDES.

FAQ Section of Install Software Command Line

Q1: How do I install software using CMD on Windows?

Open Command Prompt or PowerShell as administrator and run winget install <app-name>. Winget is built into Windows 10 and 11, so no extra setup is needed before your first install.

Q2: Is winget better than Chocolatey?

Winget is simpler and built-in, making it the better default for most people. Chocolatey has a larger, older package library and more scripting flexibility, so it’s better suited to complex or large-scale deployments.

Q3: Do I need administrator rights to install software from the command line?

Usually yes, for system-wide installs on Windows and Linux (sudo on Linux, “Run as administrator” on Windows). Tools like Scoop and Homebrew install to your user account instead, so they typically don’t require elevated permissions.

Q4: How do I install software on a Mac without using the App Store?

Install Homebrew, then run brew install <package> for command-line tools or brew install --cask <app> for full desktop applications. Homebrew handles the download and setup automatically.

Q5: How do I check if software is already installed via the command line?

Use your package manager’s list command: winget list on Windows, brew list on macOS, or apt list --installed on Debian/Ubuntu. This shows everything currently managed by that tool.

Q6: Why does my terminal say “command not found” right after I installed something?

The app usually installed correctly, but your current terminal session hasn’t picked up the updated PATH yet. Close and reopen your terminal window and try the command again.

Q7: Can I install multiple programs with one command?

Yes. Most package managers accept multiple package names in one line (brew install git node python), or you can chain separate commands together with &&.

Q8: Is it safe to install software from the command line?

It’s as safe as the source you’re pulling from. Stick to official package manager repositories, avoid running unfamiliar scripts piped directly into your shell, and only grant admin rights when a tool genuinely asks for them.