Take Control of Your Computer: Why Every Textsmith Should Learn Shell Scripting

Ishe Chinyoka

- 5 minutes read

Table of Contents

One of the most common questions from newcomers to Linux is this:

Should I learn Bash, or should I just learn Python?

It is an understandable question. Based on my own experience, I think I have a right to say that the one that addresses your own need fits the bill.

You may be tempted to start with other general programming languages like Python, Go or rust. Python has become the universal programming language of our age. It powers data science, artificial intelligence, web applications, automation, and scientific computing. A huge amount of modern infrastructure depends on Python, and every aspiring programmer will benefit from learning it.

But there is another language that quietly powers almost every Unix workstation and server.

That language is the shell.

If Python teaches you how to build software, the shell teaches you how to control your computer.

Those are not competing goals. They complement one another.

Your first shell script probably wasn’t called a script

One of the delightful peculiarities of Bash is that most people begin writing shell scripts without realizing it.

Suppose you type this command:

find . -type f -name "*smith*" \
| grep processing \
| sed -e 's/\(text-\)processing/\1smithing/g'

Most people describe this as “just a pipeline.”

But from Bash’s perspective, it is already a program.

It has:

  • inputs,
  • processing stages,
  • outputs,
  • command composition,
  • and error handling supplied by the shell itself.

The only thing separating this from a shell script is saving it into a file:

#!/usr/bin/env bash

find . -type f -name "*smith*" \
| grep processing \
| sed -e 's/\(text-\)processing/\1smithing/g'

You have crossed into programming almost by accident.

That is one of Bash’s greatest strengths.

The shell grows naturally out of the commands you already use every day.

Unix was designed for this

The Unix philosophy encourages writing small programs that each solve one problem well.

Instead of building giant monolithic applications, Unix expects you to compose existing tools.

Consider a typical day’s work.

You might:

  • search for files,
  • rename them,
  • extract certain lines,
  • count words,
  • archive the results,
  • email yourself a report.

None of these requires writing a hundred lines of Python.

Instead, you combine:

  • find
  • grep
  • sed
  • awk
  • sort
  • uniq
  • tar
  • gzip
  • mail

The shell is the language that binds these tools together.

Without it, the Unix toolbox becomes a collection of isolated utilities.

With it, they become an orchestra.

Automation begins with repetition

Most shell scripts start from a familiar feeling.

“I type these five commands every morning.”

That is the perfect moment to write a script.

Instead of remembering the sequence forever, you teach your computer.

Perhaps every morning you update your repositories:

git pull
quarto render
rsync -av public/ server:/var/www/html/

Three commands.

Tomorrow they become:

publish-blog

The computer remembers.

You move on to more interesting work.

Automation is not about replacing people.

It is about replacing repetition.

The shell speaks the language of the operating system

Python is portable.

The shell is native.

Every Unix system already understands shell commands.

Need to:

  • install software,
  • create users,
  • rotate log files,
  • restart services,
  • check disk usage,
  • schedule backups,
  • inspect processes,
  • manipulate permissions?

The documentation almost always gives shell commands.

System administration is largely a conversation with the operating system, and the shell is its native language.

Learning Bash means learning to speak directly to Unix itself.

Cron still expects shell commands

Long before cloud automation became fashionable, Unix already knew how to automate work.

Every night.

Every hour.

Every Monday morning.

Every five minutes.

Cron has quietly performed millions of jobs across servers for decades.

Most cron jobs are simply shell commands.

0 2 * * * /home/ishe/bin/backup.sh

The script may invoke Python.

It may call Perl.

It may execute Rust binaries.

But the glue that schedules, launches, redirects output, logs failures, and coordinates the work is often the shell.

Understanding shell scripting makes scheduled automation far less mysterious.

Shell scripting survives the AI era

Some people wonder whether AI makes learning shell scripting unnecessary.

Quite the opposite.

AI can generate remarkably good shell scripts.

But someone still has to answer questions like:

  • Is this command safe?
  • What happens if the directory is empty?
  • Why is rm placed here?
  • What does this regular expression match?
  • Why is output redirected to /dev/null?
  • Why did the pipeline fail?

These are not merely programming questions.

They are operational questions.

An administrator who understands shell scripting can review AI-generated automation with confidence.

Someone who cannot may end up running commands they do not fully understand.

AI is an extraordinary assistant.

It is not a substitute for judgment.

Bash teaches you how Unix thinks

Python encourages abstraction.

Bash encourages composition.

Python says:

Build a program.

Bash says:

Connect programs.

Both ideas matter.

But the second is uniquely Unix.

The shell teaches habits that become useful everywhere:

  • chaining commands,
  • redirecting input and output,
  • thinking in streams,
  • filtering text,
  • handling files,
  • automating repetitive work,
  • composing small tools into larger solutions.

Those habits remain valuable whether your next language is Python, Rust, Go, or something that has not yet been invented.

The hidden curriculum

Many experienced Linux users eventually notice something surprising.

The most productive administrators are not necessarily those who know the most programming languages.

They are often the ones who have accumulated hundreds of tiny shell scripts.

Little utilities.

Personal commands.

Backup scripts.

Deployment scripts.

Search scripts.

Maintenance scripts.

None of them is especially impressive on its own.

Together, they become a personalized operating system.

Every script captures a small piece of experience.

Every script saves a few minutes.

Over months and years, those minutes accumulate into hours.

Eventually they become expertise.

The Textsmith’s Take

Shell scripting is less about becoming a programmer than becoming a better computer user.

It encourages you to stop repeating yourself.

It teaches you to combine small tools instead of searching for giant applications.

It helps you understand how your operating system actually works.

Python may be today’s universal programming language, and every modern textsmith should learn it. Yet when it comes to daily system administration, automating routine tasks, orchestrating the Unix toolbox, and turning one-off commands into reliable workflows, the shell remains indispensable.

A textsmith learns to write.

A system administrator learns to automate.

Shell scripting is where those two worlds meet.