Skip to content
Latchkey

What Is a Shell? The Command Interpreter Explained

A shell is a program that takes the commands you type, interprets them, and asks the operating system to carry them out.

Every line in a CI script, every run: block in a workflow, is handed to a shell. The shell parses the text, expands variables and wildcards, launches the right programs, and reports back whether they succeeded. Understanding the shell explains why a script behaves differently depending on which shell runs it and which options are set.

What a shell does

A shell reads a line of input, splits it into a command and its arguments, performs expansions (variables, globs, command substitution), then starts the program and waits for it to finish. It is both an interactive prompt and a scripting language.

Interactive vs scripted use

When you sit at a terminal, the shell prompts you for one command at a time. When it runs a script, it reads commands from a file top to bottom. CI almost always uses the scripted, non-interactive mode, which behaves slightly differently from your local prompt.

Common shells

  • sh: the minimal POSIX shell, the lowest common denominator.
  • bash: the most common Linux shell, with many extra features.
  • zsh: the default on modern macOS, bash-compatible for most scripts.
  • PowerShell: the default shell on Windows runners.

Why the shell matters in CI

A workflow step that works on your laptop can fail in CI because a different shell, or the same shell with different options, parsed your script. Knowing which shell runs and which flags are set is the first step to debugging a flaky script.

A quick example

The line cp build/*.js dist/ is not understood by the operating system directly. The shell expands build/*.js into a list of matching files first, then invokes cp with that list. No shell, no expansion.

Shells on managed runners

On a managed runner like Latchkey, each step launches a fresh shell with a predictable default, so scripts behave the same way on every run. That consistency makes failures reproducible instead of "works on my machine" mysteries.

Key takeaways

  • A shell interprets your commands and asks the operating system to run them.
  • CI runs the shell in non-interactive, scripted mode, which can differ from your prompt.
  • Which shell and which options are active directly shape how a CI script behaves.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →