Shell

Linux hub

A shell is a command-line interpreter that reads user input, executes commands, and returns output. Bash is the standard shell on Linux servers. The shell is both an interactive interface and a scripting language for automation.

Understanding the Linux Shell

What Is a Shell in Simple Terms

The shell is the layer between you and the Linux kernel. When you type ls, you are not talking directly to the kernel — you are talking to the shell, which interprets your command, calls the right kernel functions, and displays the result.

Every terminal session on a Linux server runs a shell. When you SSH into a production server at Swiggy, the first thing you see is a bash prompt — that is the shell, ready for commands.

How It Works

◈ DIAGRAM

+------------------------------------------+
| You type: ls -la /var/log/               |
+------------------------------------------+
                    |
                    v
+------------------------------------------+
| Shell (bash) parses the command          |
| Expands wildcards, variables, aliases    |
| Finds ls binary: /usr/bin/ls            |
+------------------------------------------+
                    |
                    v
+------------------------------------------+
| Kernel executes /usr/bin/ls              |
| Reads directory entries from filesystem  |
| Returns output to shell                  |
+------------------------------------------+
                    |
                    v
+------------------------------------------+
| Shell displays output to terminal        |
+------------------------------------------+

Shell types and when to use each:

Bash

## Check which shell you are using
echo $SHELL
## /bin/bash
 
## Check current shell (may differ from login shell)
echo $0
## bash
 
## bash -- default on most Linux servers
## Best for: scripting, automation, DevOps work
bash --version
 
## sh -- POSIX-compatible minimal shell
## Best for: portable scripts that run on any Unix
sh --version
 
## zsh -- extended bash with better tab completion
## Best for: developer workstations
zsh --version
 
## fish -- user-friendly but not POSIX-compatible
## Best for: interactive use, not scripting

Login shell vs interactive shell vs non-interactive:

◈ DIAGRAM

Login shell (SSH session, su -):
  Sources: /etc/profile -> ~/.bash_profile -> ~/.bashrc
  Use: full environment setup
 
Interactive non-login shell (new terminal in existing session):
  Sources: ~/.bashrc only
  Use: daily terminal work
 
Non-interactive shell (scripts, cron jobs):
  Sources: nothing by default
  Use: automation -- PATH is minimal, be explicit

Practical Commands

Bash

## List available shells
cat /etc/shells
 
## Change login shell
chsh -s /bin/zsh
 
## Run a command in a specific shell
bash -c 'echo $BASH_VERSION'
sh -c 'echo hello from sh'
 
## Check if running interactively in a script
if [ -t 0 ]; then
  echo "Running interactively"
else
  echo "Running non-interactively (script or pipe)"
fi

Troubleshooting

Symptom	Command	What to Check
Command not found	`which commandname`	Not in PATH for this shell
Script works manually not in cron	`echo $SHELL` in cron	Cron uses /bin/sh not bash
Alias not in script	`type aliasname`	Aliases not exported to sub-shells

Tip
Always use #!/usr/bin/env bash as the shebang line in scripts instead of #!/bin/bash. The env version finds bash wherever it is installed, making scripts portable across systems where bash may be at a different path.

Remember
Scripts run by cron use a non-interactive, non-login shell. None of your .bashrc aliases, functions, or PATH additions are available. Always use absolute paths in cron scripts.

Frequently Asked Questions

Why do so many Linux tools default to Bash specifically, and not just 'a shell'?

Bash (Bourne Again SHell) became the default login shell on most Linux distributions because it's GNU's free, POSIX-compatible reimplementation of the original Unix Bourne shell, and it shipped as standard since the early 1990s. Scripts written for Bash aren't always portable to other shells like `dash` (which some distros use for `/bin/sh` for speed) because Bash supports extensions — arrays, `[[ ]]` tests, process substitution — that aren't in POSIX sh.

What's a common shell scripting mistake that causes production incidents?

Not quoting variables (`rm -rf $DIR` instead of `rm -rf "$DIR"`), which breaks or does something dangerous the moment the variable contains a space, glob character, or is unexpectedly empty. A close second is forgetting `set -euo pipefail` at the top of a deployment script, which means a failed command in the middle of the script gets silently ignored and the script continues as if nothing went wrong.